You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
The text was updated successfully, but these errors were encountered: