On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac <mobrovac(a)wikimedia.org> wrote:
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.
Ok, so in this vision RESTBase is a caching layer for revisions
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].
So, now RESTBase has become a router and an auth provider as well?
(Gabriel already clarified me that "monitoring" means that RESTbase
will expose its own metrics for that specific service, so this is not
monitoring of the service at all, rather accounting).
I need some clarification at this point - what is RESTBase really
going to do? I'm asking because when I read "RESTBase will provide
them with routing, [...] and authorisation" I immediately think of a
request router and a general on-wiki auth provider. And we already
have both, and re-doing them in RESTBase would be plainly wrong.
Maybe you intend very specific things when you say "routing" and not
request routing, which is what everybody here will think of.
And when you say "auth" you mean that RESTBase implements an auth
schema for its clients, so that no client can access data from another
one. If this is the case, I have some further questions: is this going
to be RBAC? Which permissions models are you implementing? Are we sure
it is what we will need? And foremost: will this be exposable to
external consumers? will it be able to hook up to our traditional wiki
auth scheme?
Can you please expand a bit on those concepts? Or a lot of confusion,
uncertainty and doubt will spread amongst your fellow engineers,
resulting in an hostile view of what may be a perfectly well designed
software.
Cheers,
Giuseppe