On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke gwicke@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.htm...
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.