On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling tstarling@wikimedia.org wrote:
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.
Actually, RESTBase's logic applies to the Mobile Apps case quite naturally. When a page is fetched and transformed, it can be stored so that consequent requests can simply retrieve the transformed document form storage.
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?
Good point. Ideally, what we would need to do is provide the right tools to developers to create services, which can then be placed "strategically" around DCs (in cooperation with Ops, ofc). For v1, however, we plan to provide only logical separation (to a certain extent) via modules which can be dynamically loaded/unloaded from RESTBase. In return, RESTBase will provide them with routing, monitoring, caching and authorisation out of the box. The good point here is that this 'modularisation' eases the transition to a more-decomposed orchestration SOA model. Going in that direction, however, requires some prerequisites to be fulfilled, such as [1].
Marko
[1] https://phabricator.wikimedia.org/T84923
Marko Obrovac Senior Services Engineer Wikimedia Foundation