I think the way we'd want to go is roughly to have a *partnership between*
the Services and Mobile teams produce and maintain the service.
(Note that the state of the art is that Mobile Apps are using Mobile Web's
MobileFrontend extension as an intermediate API to aggregate & format page
data -- which basically means Max has done the server-side API work for
Mobile Apps so far.)
I'd expect to see Max and/or someone else from the Mobile team
collaborating with the Services team to create what y'all need:
1) something that does what Mobile Apps needs it to...
2) and can be maintained like Services needs it to.
In general I'm in favor of more ad-hoc project-specific teams rather than
completely siloing every service to the Services group, or every mobile UI
to the Mobile group.
-- brion
On Wed, Feb 4, 2015 at 2:29 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote:
On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke
<gwicke(a)wikimedia.org>
wrote:
Regarding general-purpose APIs vs. mobile: I
think mobile is in some
ways a
special case as their content transformation
needs are closely coupled
with
the way the apps are presenting the content.
Additionally, at least until
SPDY is deployed there is a strong performance incentive to bundle
information in a single response tailored to the app's needs. One
strategy
employed by Netflix is to introduce a second API
layer
<
http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.ht…
on
top of the general content API to handle device-specific needs. I think
this is a sound strategy, as it contains the volatility in a separate
layer
while ensuring that everything is ultimately
consuming the
general-purpose
API. If the need for app-specific massaging
disappears over time, we can
simply shut down the custom service / API end point without affecting the
general API.
I can definitely understand that motivation for providing mobile specific
service layer - so if the services team wants to implement the API in this
way and support that architecture, I am totally on board.
My remaining hesitation here is that from the reading of this proposal, the
mobile team is the owner of implementing this service, not the services
team (Maybe I am misreading?).
This leads me to ask questions like:
Why is the mobile apps team investigating which is the best server side
technology? That seems outside of our domain knowledge.
Who will be responsible for maintaining this code?
Who will be testing it to make sure that is performant?
I'm new, so maybe these answers are obvious to others, but to me they seem
fuzzy when responsibilities are divided between two teams.
I would propose that this be a project that the Services Team owns. And
that the Mobile Apps Team defines specs on what they need the new service
to provide.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l