[~peter.braun] as always very thorough!
It seems that we indeed will need specific implementations for each of the JS SDK target runtimes (cordova, RN, web), thus extending the proposal at https://github.com/aerogear/proposals/pull/25 to include those cases.
We've defined that at least the self-defense checks and the oauth client implementations would require native code, with wrapping our own native SDK or utilizing existing libraries both being possible solutions.
I think the next step should be spiking the structure of one of those implementations, bearing in mind that the js-sdk repo is already set up as a lerna monorepo, easily allowing us to create a lot of separate packages.
I believe we could have the set of js-sdk modules set up such that the native implementations themselves are plugin-like, and top level modules for each part of the SDK unifying their APIs via UMD modules.
So the dependency tree could look like:
{code}
- @aerogearservices/self-defense (typescript -> typings + umd for the unified API)
- @aerogearservices/self-defense-cordova
- @aerogearservices/self-defense-react-native
- @aerogearservices/self-defense-web (maybe a noop or a browser-specific implementation that checks for i.e. https, browser versions with vulnerabilities etc.)
- @aerogearservices/core (for publishing the self-defense metrics)
{code}
For the platform-specific packages the top level one would be a peer-dependency and for the top one they could be set as optional dependencies for better metadata.
Instructions for each platform would be available on the top level package's documentation, and later on @aerogearservices/self-defense could have a post-install action that tries to determine the type of application it's being installed in and tries to get the correct package + run the appropriate linker. |
|
