How about we stop build-side render HTML

[peterbe]

To get fully rendered HTML to the client, you have to do some sort of "server-side rendering". Aka. SSR.
It basically involves Node rendering some content structs with some React code through. I.e. import { renderToString } from "react-dom/server";
But it's also about doing all sorts of other stuff with the HTML which we use cheerio for. We basically take the HTML string from renderToSstring(), combine it with an index.html template, and then use cheerio to mutate pieces of it and finally, return the fully formed HTML.

What I'm wondering is; how about we stop building the HTML as a cronjob build step in GitHub Actions and instead do it in a web server running Node. Runtime SSR rendering. We'll still build all the content (as index.json files) in a build-step and have that uploaded to some storage service.

This is almost how the old Kuma front-end used to work. Except it would do everything at runtime except kumascript rendering because the kumascript rendering is done once and its results stored in MySQL.

The advantage of still building all the content (i.e. producing the index.json and _samples/index.html) files is that you can then get a complete picture of what all the content is. So you can produce things like sitemaps.xml and search-index.json and it also gives you a complete bundle for uploading to Elasticsearch. And having a complete build of everything that can be built you can know what is now leftover waste (e.g. pruning).

Let's not talk about Django vs. Express or Kubernetes vs. serverless. But one thing I'd be very much interested in is to make the CDN a lot different by having all traffic routed back to a custom backend. (That backend could be Lambda@Edge!) That backend then gets a URL and if the URL is something like /en-US/docs/Web/Foo it, in run-time, goes to download the <bucketURL>/main/en-us/docs/web/foo/index.json and then uses that to run what is today ssr/index.js and then returns the fully formed HTML plus an aggressive (~1day) Cache-Control so it doesn't have to do that again for a while.

[peterbe]

Note-to-self; When we build all of en-us (i.e. client/build/en-us) it comes to about 1.3GB for all the index.html, index.json, _samples_, and images.
If you delete all the index.html files the whole en-us becomes 445MB.

[peterbe]

One advantage of not letting CloudFront do its own S3 lookup and hardcoded 404 handling is that we could manage that ourselves. I.e. If the request came in for /fr/docs/Webb/JawaScript we can return an appropriately rendered 404 HTML page based on fr. This is not possible today.

[peterbe]

With our current Jamstack approach, launching new content and launching new functionality (CSS, JS, logos) is tied to run on the same exact cadence. Suppose we disconnect these, we could launch a new CSS change more or less as soon as it hits main. (continuous deployment).

[peterbe]

Suppose we make our yarn build only generate the index.json files (and of course all the static assets such as client/build/static/css/*) the difference, as a build, is as follows:

• WITH SSR HTML
  • Built 11,719 pages in 9.0 minutes, at a rate of 21.7 documents per second.
  • Total size of build: 1.5G
• WITHOUT SSR HTML
  • Built 11,719 pages in 5.8 minutes, at a rate of 33.9 documents per second.
  • Total size of build: 550M

[peterbe]

Another not-so-crazy thing is that if we could NOT worry about SSR rendering, but only generate the index.json that could be more easily cached. A cache key could be made to depend only on the builder code and the ks macros. Sooo many documents don't change at all between cronjob builds where SSR needs to be different because a single edit to a .sass file would generate a different index.html because of the hash in the <link rel=stylesheet href=...> tags.
We could use GitHub Actions caching to store the previously generated index.json files, by a hash, and stand to save a lot of building because the caching strategy hasn't changed between daily builds.
It could get so performant that we could build the entire site in a few minutes several times a day.
/me dreaming.

[Ryuno-Ki]

What could be possible downsides?
SSR would require several runs to produce almost the same HTML every time, doesn't it?
Could it build different pieces that get stitched together to avoid invalidation of too costly pieces?
Do we have heuristics on which parts change more often than others?

[peterbe]

The obvious downside is that it's going to be a bit slower on cold CDN hits.
Today, a cold CDN hit means that Cloudfront + Lambda@Edge will go and get the index.html content from S3 which requires no Node work at all.

But it's also somewhat doable to calculate. We have 50k documents. So if every single document is requested at least 1 time per day, you have to do 50k SSR renderings in some Express Node server. But a CDN edge location might not share its cache with another edge location, so within the 24 it becomes possible that a central server has to generate the same exact HTML twice to satisfy 2 different CDN edge location requests. So perhaps you'll have to make 100k requests per day.
But that's only

And for each individual one, more things can go wrong when you have to run code each time. Now you might need to add a Sentry/Rollbar thingy in the server(less) so you can learn from failed SSR builds. When all the SSR is happening before anything is published, nothing goes out.