On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling <tstarling(a)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