Closed wtrocki closed 7 years ago
@wei-lee @david-martin Are you ok with proposed solution? Any alternatives ?
as we have discussed, I think it's best for fh-sync to know nothing about the server implementation - it will be used as a library and developers can mount it to any route of their application.
We can also provide a default implementation of a server here using Express, mount fh-sync to the default route that is expected by the client SDK to make it easier to develop and tests.
We can also add more docs/samples to show how to init the sync service and mount it onto other http servers, like Hapijs, Koa etc.
@wtrocki @david-martin @aidenkeating WDYT?
@wei-lee Probably misunderstanding but I have one question.
Would these changes require a change to the client SDK to allow for the default sync endpoint to be modified to whatever the user decides?
Edit: Derp. Didn't realise this wasn't fh-mbaas-api repo!
@aidenkeating if we provide fh-sync as a library and allow user to mount it to any route on the server, then yes we will need to change the client sdk - I think it's best to extra the sync client out of the SDKs to become its own.
Resolved by @david-martin by removing all mbaas-express dependencies. Sync now can be used directly as dependency to fh-mbaas-api
For the moment if application needs any other elements fh-mbaas-api components it cannot be used together with sync and we cannot mount 2 same mbaas-express implementations.
Best solution will be to move sync api directly into sync module. This will make fh-mbaas-api and new sync module fully independent of each other.
TL;DR Sync still requires mbaas-express to mount routes.
See: https://github.com/feedhenry/fh-mbaas-express/blob/23789d497a57a74e3fcbf7f77811a0dc271edab7/lib/mbaas.js#L185-L193