Towards personalized SSG

[eric-burel]

Overview

What is it?

• Feature / enhancement
• Bug
• Docs / tests / types / typos

Description

Hi folks,

I am just discovering Qwik, coming from Next.js with a solid experience regarding static rendering.

My pet peeve is the belief that static rendering is best for content that is the same for all visitors. I think this doesn't give static rendering justice, because SSG is also perfectly viable for content that is the same for groups of visitors.

So, my proposal:

• first I've changed the doc in this PR to be clearer about the fact that SSG is not limited to content that is the same for all visitors. More on that below.
• then, I think it would be interesting to open up the discussion and document more advanced patterns, like redirecting to static content depending on the request. Perhaps this has been discussed already, or considered very easy, then it would be interesting to include the relevant links directly in the documentation.

This is in my opinion a relatively important matter when trying to compare Qwik with say Next.js on use cases where Next.js shines, namely content app (e-commerce websites, media websites, basically any app where you have a strong marketing service behind with contradictory requirements between rich content, personalization and performances).

I'd be eager to get Qwik developers stance on this idea!

Use cases and why

The difference between "same for everybody" and "same for groups of people" seems subtle, but actually opens up so many use cases for static rendering:

• A/B tests: some users see version A, some version B. But A and B are known in advance: let's statically render that!
• i18n: some users see language FR, some se language EN, DE...
• marketing segmentation: "top-notch VIP", "people who won't buy without a coupon", "new customers"
• dark/light theme
• multi-tenancy: the company logo in the layout changes depending on the organization you belong to.

And more broadly whatever personalization pattern you may encounter in the wild.

For previous art, I've opened similar issues with explanations:

• for Persus, a Next.js inspired Rust framework: Build-time state can be user or "segment" specific, and it's actually easy to setup framesurge/perseus#295
• for Next.js: Loosen the "public" condition on getSSP vercel/next.js#36018

And I've written articles on the topic:

• "A New Pattern For The Jamstack: Segmented Rendering" for Smashing Magazine https://www.smashingmagazine.com/2022/07/new-pattern-jamstack-segmented-rendering/
• Same idea presented at React Advanced London: https://portal.gitnation.org/contents/treat-your-users-right-with-segmented-rendering
• The math behind SSR/SSG (a bit old and hard to read but lay down some ideas): https://tinyurl.com/ssr-theory

That's for the rough idea. If you think a bit about this idea a bit more, you should quickly understand that the key to this personnalisation is to redirect the user towards the right version of the page.

In Next.js, this can be done natively using middlewares. I deplore the fact that Next.js only allows static rendering based on a route parameter, and not say cookies, headers, or URL search params. Hopefully this limitation can be bypassed by using URL rewrites. I've written another aticle showing this pattern: "Render anything statically with Next.js and the Megaparam" https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde"

I think Qwik has a similar approach so could benefit from this pattern too but not sure about the specific implementation.

Lastly, you might think: "ok but this is actually SSR coupled with HTTP caching, not SSG". Yes but no, doing static personalization at "framework level" is more flexible. HTTP cache is not evenly supported, namely it's hard to cache variations depending on a subtile change like the precise value of one cookie (Vary header and such).

Bonus: you may encounter another kind of personalization, that is altering the page at the Edge (Eleventy-style). This is great too but often limited to slight adaptations, because you have to alter already rendered HTML so you can't rely on the rendering framework at this stage.

[netlify]

👷 Deploy request for qwik-insights pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	7247c58

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[wmertens]

FWIW, I've been doing cached SSR in my react apps since 2015 or so, make a key based on hash of build, request, user, mobile browser etc, and use that to check a cache, falling back to SSR. Works great.

For me though, SSG is for allowing deploying without any server component. Is that not the case?

[eric-burel]

FWIW, I've been doing cached SSR in my react apps since 2015 or so, make a key based on hash of build, request, user, mobile browser etc, and use that to check a cache, falling back to SSR. Works great.

I wish this was more common! Modern frameworks do not really let you do that easily, you have to twist Next.js a bit to achieve that and I am still trying to learn how it's done in Qwik/Vite.

For me though, SSG is for allowing deploying without any server component. Is that not the case?

I think a distinction should be made between having no rendering server and having no server at all. Cached SSR is about avoiding to useless re-renders but it doesn't tell much about when you render, either build-time or request-time, so let's suppose you render at first request and cache the thing.

The point of SSG is indeed to allow deployment without a rendering server (read a full-fledged Node.js server that can run JS), so you have to render everything at build-time.

But that doesn't mean you cannot have a server. Actually you need only one feature to support personalized static rendering: URL rewriting, in order to point a given request to the right prerendered path (which acts as your cache key). Nginx, Route 53, Edge functions/middlewares are smart enough to support that. You can assume that this feature is not hard to implement if the developer really wants it and more broadly that nothing prevents you from rendering personalized content at build-time that is different for many users.

[lbensaad]

Thanks a lot for this effort. I am building an online ordering and invoicing SPA using Qwik. It is totally SSG served by nginx, a Jamstack. All pages are private behind auth. After each page load I fetch the needed data from Pocketbase. I loose some of the benefits of Qwik like server actions, but I found that jamstack is better me.