On Wed, Feb 4, 2015 at 5:42 AM, Tim Starling <[email protected]> wrote: > On 04/02/15 12:46, Dan Garry wrote: >> To address these challenges, we are considering performing some or all of >> these tasks in a service developed by the Mobile Apps Team with help from >> Services. This service will hit the APIs we currently hit on the client, >> aggregate the content we need on the server side, perform transforms we're >> currently doing on the client on the server instead, and serve the full >> response to the user via RESTBase. In addition to providing a public API >> end point, RESTBase would help with common tasks like monitoring, caching >> and authorisation. > > I don't really understand why you want it to be integrated with > RESTBase. As far as I can tell (it is hard to pin these things down), > RESTBase is a revision storage backend and possibly a public API for > that backend. I thought the idea of SOA was to separate concerns. > Wouldn't monitoring, caching and authorization would be best done as a > node.js library which RESTBase and other services use? >
I agree with Tim. Using RESTBase as an integration layer for everything is SOA done wrong. If we need to have an authorization system, which is different from our APIs, we need to build it separately, not to add levels of indirection. Doing 4 things from one single service is basically rebuilding the mediawiki monolith, only in a different language :) What you need, IMO, is a thin proxy layer in front of all the separate APIs you have to call, including restbase for caching/revision storage. It may be built into the app or, if it is consumed by multiple apps, built as a thin proxy service itself. (I also don't get what "monitoring" means here, but someone could probably explain it to me) Cheers, Giuseppe _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
