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(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.
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Corey Floyd
Software Engineer
Mobile Apps / iOS
Wikimedia Foundation