tl;dr; Before the Mobile Apps Team embarks on its own path, I really think we should work together as an organization to figure out a better strategy for implementing a set of consistent services that address the needs of all platforms.
So… I've been involved in similar conversations at other organizations. They generally sound like this:
"These APIs were designed before mobile. Mobile needs mobile friendly services to be great. This services currently don't exist and/or aren't being implemented fast enough for us to build the features we want. Lets implement our own services!" (Ok that was a bit contrived but you get the point)
The problem I have with this solution is two fold:
1. The owners of this services project should really be the services team. 2. Building a separate service for mobile does not align the needs of the mobile team with the rest of the MediaWiki API consumers.
To be clear - I totally agree that we should be working with services engineers to collaboratively develop APIs. In fact, Mobile Apps, along with other front end teams, should be proactively giving the services team input and support so they can build the services that we need. This results in making the API not only better for Mobile Apps, but the other platforms as well.
Working around our services issues by providing the mobile apps with different set of APIs than the rest of the platforms comes with its own set of problems. In the long run it creates more work (maintaining multiple APIs) and leads ambiguity ("Oh, that only works on the mobile API"). It also creates a new point of failure that would only affect mobile apps. This means at times consumers of the "Real API" may have needs that conflict with mobile apps and compete for the time and attention of the services engineers.
Being on iOS and Android already puts the mobile apps on an island because of the language and framework differences. Using a different API won't help that, but development of an API that serves the needs of all the platforms aligns our needs with the rest of the organization while providing all front end teams a consistent way to access data.
This doesn't even address the fact that the mobile team is staffed with experts in tuning native apps - which is quite at different skill set than writing, deploying, and maintaining server side java script. Write good scalable server code is difficult, and this will be extremely important here, since, for the foreseeable future, mobile traffic is expected to see the most growth.
It should go without saying, but I'm obviously not against Mobile App Engineers submitting patches to the API if they want to, maybe even hack using days (though rumors have it that iOS is a bit busy this quarter). But this is quite different than owning the service.
After reading this, you would probably assume all my experiences with this strategy were bad. Ironically, I was recently on a mobile team that developed its own services successfully. I even helped to come up with the Acronym: MISL (Mobile Intermediary Services Layer). :)
However, on that mobile team we had 2 experienced AND dedicated javascript/python engineers that were specifically tasked to write services/administration panels and who interfaced directly with the main services team.
(Now, If we are going to start talking about embedding web services engineers on the Mobile Apps team, I'm definitely in!)
On Wed, Feb 4, 2015 at 12:59 AM, Marko Obrovac mobrovac@wikimedia.org wrote:
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l