John Whitlock [:jwhitlock] Reporter
	Description • 8 years ago

What problem would this feature solve?
======================================
The API serves up raw data, but MDN needs to display it in tabular format, with assets served from a CDN. It also needs to refresh the cached compatibility data on page load.

Who has this problem?
=====================
All visitors to MDN

How do you know that the users identified above have this problem?
==================================================================
In December 2015, MDN had 13 million visitors. When the BC service goes into production, we need to handle 1 million daily requests for updated production data, and, in the case of updates, to render this as MDN-specific tables.

How are the users identified above solving this problem now?
============================================================
The table-rendering logic is in the kumascript EmbedCompatTable macro [1]. This allows table generation during page rendering, at save time or due to a force-refresh. After the UUID conversion (bug 1230306), this logic will be called from the CompatTable macro instead [2] This does not allow live reloading of refreshed data, without putting more load on the overburdened kuma / kumascript system.

[1] https://developer.mozilla.org/en-US/docs/Template:EmbedCompatTable
[2] https://developer.mozilla.org/en-US/docs/Template:CompatibilityTable

Do you have any suggestions for solving the problem? Please explain in detail.
==============================================================================
Convert the EmbedCompatTable macro to generic JavaScript. Create a  node.js application that will take a feature UUID and a locale, call the API to get the feature data, render the table using PhantomJS, and return it to the caller. Create cache headers based on the API's cache headers and the locale, so that a caching load balancer such as CloudFront can be used to reduce backend load.

Is there anything else we should know?
======================================
There is a dev-mdn post discussing the rendering service:

https://groups.google.com/forum/#!topic/mozilla.dev.mdn/PUGcYXQTM4c

	Jeremie Patonnier :Jeremie
	Comment 1 • 8 years ago

Hi, 

Just a question about the suggested technical stack: Why using PhantomJS if we are building a node application? This looks like a super heavy solution just to produce some HTML. It exist various solution to generate HTML content without the need of a headless browser (For example: Mustache templates [1], React [2], or raw HTML manipulated through stream with Trumpet [3]). 

[1] https://www.npmjs.com/package/mustache
[2] https://www.npmjs.com/package/react
[3] https://www.npmjs.com/package/trumpet

	John Whitlock [:jwhitlock] Reporter
	Comment 2 • 8 years ago

It's the least work to convert from EmbedCompatTable to generic JS. It is possible that the JS could be reused by third parties, or in reused in other layers, such as a MDN preview in the C&M interface, or when displaying diffs in the moderation interface. But, I'm not familiar with JS tech stacks, so maybe there is a way to use an alternate library without requiring MDN users to download it.

	Stephanie Hobson [:shobson]
	Comment 3 • 8 years ago

We need to produce HTML, not JavaScript. Mustache and React are JavaScript, to hand KumaScript HTML we need Phantom to execute the Mustache/React/JS to create the HTML. I am not familiar with Trumpet but it appears to need HTML input

We could probably do this with Python and I think we'd be more comfortable with the server environment for that but we'd have to rewrite the parser which is in JavaScript right now.

	Jeremie Patonnier :Jeremie
	Comment 4 • 8 years ago

Okay, my mistake, I though you were more familiar with the NodeJS stack. So the exact tech stack need to be discuss a little bit more in depth (I'll bring the topic to our next meeting).

But basically, to do what we need, it makes me feel very insecure to try reusing the KumaScript code as it is. It's way more efficient (and faster to develop) to set up any NodeJS HTTP server (Express, Koa, Hapi, etc.), that will request our API to feed any JS-to-HTML template system (Jade, Handlebars, EJS, etc.).

Note that if we start working with Ember, it worth considering Handlebars/Mustache as our main template system, but if you insist to reuse KumaScript code, then we can use EJS as our main template system.

Obviously if you want to go with a Python stack it's okay to, but in that case I need to be convince before being confortable with the idea of an headless browser running somewhere.

	John Whitlock [:jwhitlock] Reporter
	Comment 5 • 7 years ago

The BrowserCompat project is canceled.  See https://github.com/mdn/browsercompat for current effort. Bulk status change includes the random word TEMPOTHRONE.