"live" content pages

[samthor]

(Happy to have better name suggestions due to the obvious ambiguity.)

Problem For WDL, our master page needs to, from a user point of view, go through a number of transitions during our upcoming event.

Proposal

• In our Markdown source (or etc), we mark certain page nodes as "live"
• If we're on a page like this, the user JS fetches its partial every ~5 minutes
• This will normally give us a 304 (although fetch() sees this as 200)
• If some hash/revision changes, we silently rehydrate the page

Implications

• We'll need to have a more regular deploy process
  • or modify our server to e.g., serve pregenerated differential files based on timestamp (but invalidates #2722)
  • we already do scheduled posts
  • we have too many App Engine apps (see #2696)
• A bunch more load
  • could backoff based on lack of browser use (don't check in background, after no events)
  • rehydration could 'kill' the liveness flag

Alternatives

1. Have the client prefetch a number of different versions and change the page based on local timestamp (this is overkill because the content we're showing is elsewhere online, so ?)
2. Swap all content inline with JS

Notes There'll be no unsupported browser solution. So if we're statically including an <iframe> for a video session and a YouTube-supporting-but-not-web.dev-supporting browser opens us, they'll have to reload.

[robdodson]

Thinking about this a bit more, I'm wondering if we might be able to go a simpler (and safer) route.

If we do client-side js then we'd likely only need to deploy the site two times: Once when the event starts (we could probably do this the day before the actual start date), and once more when the event ends.

We can go ahead and build these pages and even check them in. We just need to set them to permalink: false so they don't get output.

Instead of using remote-config (which takes a while to load), we'd use client-side JS for the widgets to decide which iframe src to show for the livestream and chat. We could bootstrap the page with some JSON that contains all of the data that the event needs to power itself. Waiting on our JS to load may be a tad slower, but ultimately I think it's more reliable and easier to build and we can explore if there are ways to load it faster.

[robdodson]

For sections of the page that remain the same across versions, we could consider putting them in njk includes so we don't have to keep the different versions in sync.

[robdodson]

Another option would be to put everything in /live/index.njk and rely on conditionals to turn different sections on or off