Discussed with @GWicke at Wikimania.

Building the service immediate for handling MediaWiki traffic is gonna be quite tricky since MediaWiki's skin system isn't ready for that right now.

• Skin should be executable independent of global state. Ideally in a way that is able to share code with the Node service and/or in a way that can be exported through the API.
• All hooks must be reduced to static conditions. (But sidebar links can still vary by page or user name, tabs may vary on page meta data and user permissions, etc.).
• Need to be able to compile the skin layer down to a cacheable function (e.g. mustache template) that can be invoked with page and user data and produce the output - streamable.
• Goal: With $wgUseFileCache enabled, the Skin layer should be cacheable independently of the page and applied at run-time. For deployments that use a CDN (e.g. Wikimedia with Varnish) one would use a separate service for the skin (the composition server from this RFC).
• Benefits: 1) Response time for logged-in users comparable to that of logged-out users. 2) Skin updates apply in a unified way - at once. (Instead of gradually as different pages expire from the cache.)

I'd like to consider to first build a MVP for a non-MediaWiki use case (e.g. Wikipedia portal). We'll continue work on MediaWiki. Meanwhile, we can start making progress on the performance characteristics and implementation details of the composition server.

(wrong user, moving)

I had spent some thoughts about this problem space.

Things I had in mind (e.g. WebWorker, a null theme only basic HTML patterns, and an API view) had been outlined.

In an ideal system, we want to optimize cache opportunity, lower same resource representation variants, keep editing capability and allow customization.

Let's assume we have:

1. The article body HTML is the same regardless of which type of Web Browser you're using.
2. We create cookies only to a context root Set-Cookie: Foo=...; Path=/ui/partials; ...

Then we can

1. Create HTML "partial" renderer (e.g. what parsoid does)
2. Patch up view to a given context.
3. Use the exact same HTML to everyone regardless if user is signed-in or not
4. If user is signed in (i.e. has a cookie matching Path /ui/partials) we patch up user actions snippets into the DOM asynchronously.

To illustrate my thoughts, I've made this screen capture.

PS: Imagine it's Wikipedia instead of MDN, please.

Thought it would be useful here.

@Renoirb, what you describe is indeed pretty close to what we have in mind. We have a bit more per-user variance in the UI, mostly related to editing functionality. For example, tabs for page deletions or protection are only shown to admin users with the appropriate rights. We also want to support varying the UI by device and network conditions. We are especially interested in improving support for poor network connectivity or even offline use. Some of these changes would be difficult to pull off cleanly & with good performance by using DOM patch-ups only.

Thankfully, once a user is logged in using a modern browser, we can leverage a ServiceWorker to compose content client-side. We are currently prototyping a basic composition / templating layer with streaming support. Current work is building on elematch, but @Krinkle is also looking into supporting mustache syntax. This should give us performance data for server-side use, where we would like to run the same serviceworker code using a faux environment like https://github.com/gwicke/node-serviceworker.

I should point out that given the mobile site currently supports a much smaller subset of functionality compared to desktop it might be a good place to iterate on some of the ideas here. Currently there is very little reason we need to vary cache for logged in users of the mobile site.

On the server side the UI only changes for logged in users in the following way:

• talk link added
• notification (echo) link added to top right
• menu links / labels are different for logged in user (but all are rendered via JS - so this could easily be done at the JS level)

Viewing source of the mobile site, the main issues would be the following config variables shipped as inline js:

• wgMinervaMenuData
• wgUserName

As of last week, @GWicke and I have started to meet on a weekly basis to track progress on one of the first sub items of this task: T106099: RFC: Page composition using service workers and server-side JS fall-back.

Quick summary:

• We're working on a more detailed draft and spec for the composition server (no code yet).
• We've begun coding some of the low-level libraries required for the server. Relating to transform streams, Mustache support, and the ability to run the same code in both a ServiceWorker client and in a Node.js service.

See T106099 for more details.

A prototype service is now available at https://swproxy.wmflabs.org/wiki/Wikipedia. This is running unmodified ServiceWorker code in a server-side proxy environment equivalent to a Browser, and also installs the same ServiceWorker in modern clients. Resources are cached for offline use. See T106099 for the details.

• clean Barack - 5.5s
• w/ ServiceWorker, first load - 3s
• w/ ServiceWorker subsequent load - 2s

Very nice!

This has been closed? Has an equivalent idea started under a different name?

A lot more work was done under T114542: Next Generation Content Loading and Routing, in Practice and eventually several projects were started up. Marvin was the official one, but there were other proofs-of-concept including https://github.com/jdlrobson/weekipedia and T101732 for ResourceLoader. Eventually Marvin was archived (T205170: Archive marvin) due to npm-related security issues and lack of on-going maintenance.

A more narrow proposal, driven by specific performance and user experience outcomes, exists at T140664: Achieve predictable MediaWiki routing and cacheable skin data as part of T302623: FY2022-2023: Improve Backend Pageview Timing.

This direction would see MediaWiki (re-)embrace principle of data flowing in one direction during page view generation, and as consequence allow better caching, and better separation of concerns, reducing the skin layer to a low level of (required) complexity, and allowing some skins (e.g. those WMF-deployed) to be so fast and simple that they could potentially be run near a CDN edge, if that were notably advantagous to latency (TBD). The steps along the way each come with significant performance and code quality benefits that pay off regardless of whether that last step is taken.