Talk:Design System Team/Server rendering background info

Looking at the next step after Vue, I've become aware of Elixir's Phoenix LiveView while working on personal projects, and it shows how a better model of SSR might work. I'll briefly explain here in the hope of giving us an ideal to keep in mind—obviously it isn't feasible to rewrite our backend in another language.

The short background is that Phoenix does all rendering on the server, and if JS is available on the client then a websocket connection is opened and interactivity is implemented by sending data, events, and HTML deltas through this socket.

• (+) Constant render performance.
• (+) Low requirements for client JS support.
• (+) No need to expose custom APIs for fetching data, for example the database can be queried directly.
• (+) Reactivity is transparent to the application.
• (+) UI is declared as HTML and components, much like Vue.
• (-) Application latency is dominated by upstream network latency so there is a tradeoff along the lines of "thin vs. thick" client.
• (-) Tech stack is unfamiliar to most MediaWiki developers and SRE.

Something similar has been developed for PHP: Livewire.

There are a few other cons for server-side rendering:

• Hard dependency of the basic website functionality on a second service reduces the availability of the website by the cumulative downtimes of the SSR component and MediaWiki
• Potential real performance penalty (we're calling a nodejs service, which are not known for their stellar performance, via the network for every page view
• Loss of the ability to install mediawiki on a simple hosting platform.

Loss of the ability to install mediawiki on a simple hosting platform.

Perhaps we could allow for a graceful fallback, so if MediaWiki is running in an environment where a server-side rendering service is not present, then component rendering happens on the client-side.

Potential real performance penalty (we're calling a nodejs service, which are not known for their stellar performance, via the network for every page view

Maybe there's a way to separate out the rendering needed for unauthenticated users or otherwise generic component displays, and to cache this output, then do per-user customization as part of the client-side render?

Hard dependency of the basic website functionality on a second service reduces the availability of the website by the cumulative downtimes of the SSR component and MediaWiki

We could perhaps timebox the amount of time available for the SSR to some acceptable threshold, so e.g. if the request to the SSR service is more than 200ms, abort the request and fall back to a client side render.

I think the only way we can transform this from a potential liability to an opportunity is if we somehow integrate this with the idea of doing edge-site composition.

Also to note: you're proposing here we submit requests to mediawiki and it makes calls to the SSR; I'm not sure that is the mode they're going for here. Anyways we'll know more once we get more into discussing the details of the project.

> Loss of the ability to install mediawiki on a simple hosting platform

I don't see it this way. If implemented correctly it would gracefully degrade to no server side rendering and there would be no loss of ability.

It's acceptable for skins/extensions to be JS-only with server side rendering an additional extra which requires additional install steps.

Third party skins that are JS only already exist and Extension:NearbyPages which is installable by third parties has no SSR but would benefit from an improved experience if added.

Ok, the proposal doesn't spell out the ability to still function as pure-php as one of the requirements, but that's of course perfectly acceptable.

I apologize for the extremely late response. Between a team offsite and personal circumstances I haven't had time to respond until now. I have added two "con" points to the SSR section based on Giuseppe's comment.

As Kosta said, any approach to SSR that I would propose would involve graceful fallback behavior, both for when the Node.js service is available but temporarily down, and for when the service is not available at all (on a 3rd-party wiki where the service is not installed). As part of the initial discussion I also want us to talk about when it makes sense to use Vue SSR vs when it makes sense to use some other rendering method, and we should consider the potential unavailability (due to temporary downtime or due to not being installed) of Vue SSR as part of that.