> 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
On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac wrote:
> On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling
> 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
On Wed, Feb 4, 2015 at 6:59 AM, Marko Obrovac wrote:
> On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling
> 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
On Thu, Feb 5, 2015 at 9:00 PM, Yuri Astrakhan wrote:
> Lastly, semi related - my service will also need a node.js lib to access MW
> api. How should we manage common libs like that?
Libraries published on npm using semantic versioning and imported to
the individual services as needed.
Bryan
--
Tim, I like Varnish's vcl flexibility, but not the debugging aspects.
Still, +1, but could you elaborate on how you see:
* Services communicate with each other - via varnish as well or directly?
* Do you see routing varnish layer as non-caching, only to forward request
to the second tear service-s
On 04/02/15 16:59, Marko Obrovac wrote:
> 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
On 4 February 2015 at 15:00, Brion Vibber 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.
>
Agreed. This also ensures that the service exactly meets the functio
On Wed, Feb 4, 2015 at 4:00 PM, Brion Vibber 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 extensi
> 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
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 -- w
On Wed, Feb 4, 2015 at 11:41 AM, Gabriel Wicke 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 d
On Wed, Feb 4, 2015 at 8:41 AM, Gabriel Wicke 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 de
On 4 February 2015 at 08:40, Bryan Davis wrote:
> +1 This sort of major design change is exactly the sort of thing that
> I think the RfC process is good at helping with. Start with a straw
> man proposal, get feedback from other engineers and iterate before
> investing in code changes. The somet
> One strategy
> employed by Netflix is to introduce a second API layer
> <
> http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html
> >
> 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
On Tue, Feb 3, 2015 at 11:33 PM, Erik Moeller wrote:
> I think you will generally find agreement that moving client-side
> transformations that only live in the app to server-side code that
> enables access by multiple consumers and caching is a good idea. If
> there are reasons not do to this, n
On Wed, Feb 4, 2015 at 8:51 AM, Brian Gerstle wrote:
> TL;DR; this discussion is great, but I think moving to docs/wikis/etc.
> instead of continuing the thread could improve communication and give the
> people who end up working on this something to reference later. could just
> be my n00b-ness,
TL;DR; this discussion is great, but I think moving to docs/wikis/etc.
instead of continuing the thread could improve communication and give the
people who end up working on this something to reference later. could just
be my n00b-ness, but I thought others might share the sentiment.
I'm still new
On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller wrote:
> If not, then I think one thing to keep in mind is how to organize the
> transformation code in a manner that it doesn't just become a
> server-side hodgepodge still only useful to one consumer, to avoid
> some of the pitfalls Brian mentions.
> 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).
Yes. As an organization we should provide good tools that allow
developers to create services. I do f
On Wed, Feb 4, 2015 at 5:42 AM, Tim Starling wrote:
> On 04/02/15 12:46, Dan Garry wrote:
>> To address these challenges, we are considering performing some or all of
>> these tasks in a service developed by the Mobile Apps Team with help from
>> Services. This service will hit the APIs we current
On Tue, Feb 3, 2015 at 5:46 PM, Dan Garry wrote:
> To address these challenges, we are considering performing some or all of
> these tasks in a service developed by the Mobile Apps Team with help from
> Services. This service will hit the APIs we currently hit on the client,
> aggregate the conten
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 org
On Tue, Feb 3, 2015 at 8:42 PM, Tim Starling
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
Hey Kunal,
Responses in-line.
On 3 February 2015 at 21:09, Legoktm wrote:
>
> Is there a bug for this and the other issues? I'm subscribed to [1], but
> I don't see anything like the issues you've mentioned on it.
>
There's this, which documents some of them, but it's more descriptive of a
spec
On 02/03/2015 05:46 PM, Dan Garry wrote:
> *tl;dr: Mobile Apps will, in partnership with the Services, investigate
> building a content service for the Mobile Apps.*
>
> The Mobile Apps Team currently has quite a few pain points with the way we
> fetch article content currently:
>
>- We hav
On 04/02/15 12:46, Dan Garry wrote:
> To address these challenges, we are considering performing some or all of
> these tasks in a service developed by the Mobile Apps Team with help from
> Services. This service will hit the APIs we currently hit on the client,
> aggregate the content we need on t
Thanks for getting this ball rolling, Dan! Couldn't agree more with the
points you raised—having in fact raised a few of them myself. Put me down
as one of the mobile/full-stack engineers who wants to work on this service
:-).
On Tue, Feb 3, 2015 at 8:46 PM, Dan Garry wrote:
> *tl;dr: Mobile App
*tl;dr: Mobile Apps will, in partnership with the Services, investigate
building a content service for the Mobile Apps.*
The Mobile Apps Team currently has quite a few pain points with the way we
fetch article content currently:
- We have to make a lot of API requests to load an article: artic
28 matches
Mail list logo
