develwoutacause’s Twitter Archive—№ 1,248

Interesting discussion on @JSPartyFM where @kentcdodds suggests recontextualizing a static site generator (SSG) as a server-side rendered (SSR) application gated by an immutable cache. I'd never really thought of it along those lines. changelog.com/jsparty/215#transcript-28
Permalink On twitter.com ♻️ 8 Retweets ❤️ 21 Favorites 2022 Mar 21 Mood +2 🙂

…in reply to @develwoutacause
This approach allows SSG and SSR routes to share the same implementation and evolve over time. A currently SSG route can become an SSR route just by changing the caching strategy, which sounds really flexible and powerful.
Permalink On twitter.com ❤️ 2 Favorites 2022 Mar 21 Mood +3 🙂

…in reply to @develwoutacause
It also makes SSG routes lazy for development. You don't have to build all 1,000 pages for your site, just the one you're currently debugging. It converts your dev workflow from O(total # of pages in the app) to O(1), which is a huge improvement! 🤯
Permalink On twitter.com ❤️ 3 Favorites 2022 Mar 21 Mood +2 🙂

…in reply to @develwoutacause
The downside is that cache invalidation is hard. New releases blow away the cache and the first user to request a page has to pay the cost normally paid at build time for a traditional SSG site. This means your SSG computations now fall under your request/response SLOs. 😱
On twitter.com ❤️ 1 Favorite 2022 Mar 21 Mood -4 🙁

…in reply to @develwoutacause
For small/simple pages, that might be fine and you don't care. You could also set up your release process to proactively query all SSG routes of the application and update the cache, so unlucky users don't pay that cost. I'm sure @remix_run can build that if it doesn't exist. 🤔
Permalink On twitter.com 2022 Mar 21 Mood +1 🙂

…in reply to @develwoutacause
For truly dynamic applications you also now have a fourth execution context. 1. Build time (traditional SSG). 2. SSR of SSG pages. <-- New 3. SSR pages. 4. Client side rendering (CSR).
Permalink On twitter.com ❤️ 1 Favorite 2022 Mar 21 Mood 0

…in reply to @develwoutacause
1. Doesn't go away because you still need it to compile JS, CSS, etc. You wouldn't want to do that on the server. 2. and 3. are similar, but not *quite* the same since the caching differences place unique invariants on each (2. can't look at HTTP requests, 3. has hard SLO's).
Permalink On twitter.com 2022 Mar 21 Mood 0

…in reply to @develwoutacause
I don't really have a point to make here, just that building an SSG app via SSR with an immutable cache is an interesting design choice with some unique and non-obvious trade-offs. Interesting discussion nonetheless! 🤔💭
Permalink On twitter.com ❤️ 1 Favorite 2022 Mar 21 Mood +4 🙂