Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructuring plan for browser support #225

Closed
nfriedly opened this issue Mar 29, 2016 · 4 comments · Fixed by #288
Closed

Restructuring plan for browser support #225

nfriedly opened this issue Mar 29, 2016 · 4 comments · Fixed by #288
Assignees

Comments

@nfriedly
Copy link
Contributor

Several Watson services currently support CORS, and others will soon (hopefully). Users will try to use the Node.js SDK in a web browser (via browserify, etc.) but it fails with "file not found" sorts of errors when trying to create a service instance due to the way that we programmatically require modules on demand.

A simple fix might be to just require() everything at the top level, and this should probably be part of the strategy so that we can generate a single bundle.js for browsers that includes all supported Watson services (and helpful error messages when a user attempts to use services that do not support CORS in a browser - this is easy to automate with browserify).

However, I think this is a good opportunity to take things a step further:

  • Allow users to require('watson-developer-cloud/some-service/v1') so that they can create their own bundles with only the code they're using.

  • The above step requires a slight re-organizing of the code (moving service folders out of services/ to the top level), so it may be a good time to re-organize the readme, examples, and tests, and group things by service instead of type.

    The readme in particular is getting a bit hairy. Having a separate readme for each service could help. (Alternatively, we could just move things into the comments, and have the readme link to the JSDoc... I'm not as sure about this point, but wanted to bring it up for discussion.)

  • Switch to ES6 modules to allow for tree-shaking (even smaller file size) and nicer syntax (we can also include pre-compiled copies of everything in the npm releases - deployment is automated, so there aren't any extra manual steps to remember.)

  • Combine the Node & Browser SDKs into a single "JavaScript SDK" that runs everywhere

@germanattanasio, @jsstylos, & @jzhang300: what do you guys think?

@austinkelleher
Copy link
Contributor

I would really like to see these changes happen!

@germanattanasio
Copy link
Contributor

major release ?

@nfriedly
Copy link
Contributor Author

nfriedly commented Apr 1, 2016

i think we can do the changes in v1.x w/ helpers to provide backwards-compatiibility, and then drop the helpers in the next major release.

@dselman
Copy link

dselman commented Apr 6, 2016

Would love to see this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants