On Tue, Feb 3, 2015 at 5:46 PM, Dan Garry <[email protected]> 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 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.
Using https://phabricator.wikimedia.org/T87824 as a reference point for what you're talking about - 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, now'd be a good time to speak up. 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. Say you want to reformat infoboxes on the mobile web, but not do all the other stuff the mobile app does. Can you just get that specific transformation? Are some transformations dependent on others? Or say we want to make a change only for the output that gets fed into the PDF generator, but not for any other outputs. Can we do that? Or a more pressing concern for the app team itself, what about alpha, beta, stable version of the apps -- how would those get more/less experimental versions of the output? Or languages -- are there cases where we apply a transformation only in one language, but not another? Do we need a way to register schemas so we can easily get a certain set of inter-dependent transformations, like "mobile app stable", "desktop web", etc.? Or are these all just API/service parameters? Just some early questions as we're thinking this through. Erik -- Erik Möller VP of Product & Strategy, Wikimedia Foundation _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
