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.=
Agreed, as long as everyone deploying services communicates through
services team so there is no duplication of solutions.
We should have 1 routing layer, standard monitoring and standard caching as
it is been pointed out before. Specifics of services might be different but
it seems the core mission of service team to provide common infrastructure,
right?.
That means that the 1st service we develop will be more work for services
team than subsequent services. *Ideally* the mobile team should develop the
service without having to solve (for example) any caching problems that are
not mobile specific.
On Wed, Feb 4, 2015 at 3:04 PM, James Douglas <jdouglas(a)wikimedia.org>
wrote:
>
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.
>
> I strongly agree. Based on experience on both sides of this spectrum, I
> recommend (when feasible) favoring feature teams over functional teams.
>
> On Wed, Feb 4, 2015 at 3:00 PM, Brion Vibber <bvibber(a)wikimedia.org>
> wrote:
>
> > 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
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>