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 <[email protected]> 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 have to make a lot of API requests to load an article: article > HTML, lead image, read more recommendations, and more > - We send the user HTML that we then discard, needlessly increasing data > usage > - We do transforms to the HTML in JavaScript on the client side, which > causes code duplication across the apps and degrades user-perceived > performance > - Trivial changes to the API (e.g. renaming a parameter) can break the > app which is problematic since apps can't be hotfixed easily > > 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 the server side, perform transforms we're > currently doing on the client on the server instead, and serve the full > response to the user via RESTBase. In addition to providing a public API > end point, RESTBase would help with common tasks like monitoring, caching > and authorisation. > So the Mobile Apps Team is going to spend a bit of time investigating > whether using RESTBase with Node.js is an option for building a content > service for the Wikipedia app to replace our current method of retrieving > article content. Our initial scope for this is feature parity with our > current content retrieval method. > > Our action items are as follows: > > - Wait for RESTBase to be deployed. > - Timescale: Weeks > - Owner: All of us :-) - Figure out what information the service should serve for the first > iteration (i.e. for feature parity) and what APIs it needs to hit to do > that > - Timescale: Wed 4th Feb > - Owner: Dan Garry > - Start implementing the service and see whether it meets our needs > - Timescale: Planning a spike for next apps sprint (16th Feb - 27th Feb) > to perform initial investigation > - Owner: Currently undecided engineer from Mobile Apps, with Services > engineers serving as consultants > > As always, feel free to ask if there are any questions. > > Dan > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
