On Tue, Feb 3, 2015 at 11:33 PM, Erik Moeller <e...@wikimedia.org> 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, 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? > Right now the plan is to start from plain Parsoid HTML. The mobile app service would be called for each new revision to prime the cache / storage. Chaining transformations might be possible, but right now it's not clear that it would be worth the complexity. Currently AFAIK only OCG and mobile apps have strong transformation needs, and there seems to be little overlap in the way they transform the content. Mobile web still wraps sections into divs, but we are looking into eliminating that by possibly integrating the section markup into the regular Parsoid output. 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.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 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. Gabriel _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
