3 ms·

There is always a server, CDN are servers, so even a totally static websites exported as HTML pages can benefit for user-level or segment-level personalization

There is always a server, CDN are servers, so even a totally static websites exported as HTML pages can benefit for user-level or segment-level personalization if the host has enough features. A simple URL rewriting layer is the only thing you need. Your mental model is consistent with what I see from Perseus, but I think that Next is already one step ahead, and this step is to understand that there is a always a server and a user request around even when you render statically. This was my initial point, probably poorly phrased.

Tehnix 4y ago
> There is always a server, CDN are servers Sure, but in common parlance that’s not really a useful point. There are also servers involved in serverless, but we’ve largely accepted that here it is meant to indicate (on a gradient) who manages those servers :) When you set up your infrastructure, it will matter quite a lot whether you’re able to utilize a CDN as the only thing you need to deploy to, or if you need to run your own code at runtime (and hence need a something to run it on). It’s worth noting: You can absolutely go for all of these solutions! I do have a bit of a penchant for solutioning things that I know will scale up massively, but that is not always a priority early on, so I don’t want anyone to be discouraged by these approaches and the other benefits they can provide :) > there is always a server and a user request around even when you render statically I’d love to dive into that part a bit more, genuinely curious! Is the point that there is always dynamic information to act on to improve the user experience? Or what would be the goal or vision once you know that?
- eric-burel 4y ago
  I am mostly thinking about personalization (AB tests, i18n, marketing segment, multi-tenancy belongs to this family of use cases), it's often assumed that you can't achieve personalization with static rendering, and that's just not true: a simple (read very fast, very cheap, optimized for this use case, like CDN are supposed to be) URL rewriting server can point to the right statically rendered page at request time. Another approach is modifying the page at the edge, Eleventy does that. All this involve being aware that your static content will be accessed using an HTTP request, taking that into account may lead to a more unified (not squashed though, just unified) SSR/SSG architecture similar to Next 13 one. You can look for Plasmic take on AB tests with Next or my own work on Segmented Rendering or the "megaparam" pattern.

Tehnix 4y ago

> There is always a server, CDN are servers Sure, but in common parlance that’s not really a useful point. There are also servers involved in serverless, but we’ve largely accepted that here it is meant to indicate (on a gradient) who manages those servers :) When you set up your infrastructure, it will matter quite a lot whether you’re able to utilize a CDN as the only thing you need to deploy to, or if you need to run your own code at runtime (and hence need a something to run it on). It’s worth noting: You can absolutely go for all of these solutions! I do have a bit of a penchant for solutioning things that I know will scale up massively, but that is not always a priority early on, so I don’t want anyone to be discouraged by these approaches and the other benefits they can provide :) > there is always a server and a user request around even when you render statically I’d love to dive into that part a bit more, genuinely curious! Is the point that there is always dynamic information to act on to improve the user experience? Or what would be the goal or vision once you know that?

eric-burel 4y ago
I am mostly thinking about personalization (AB tests, i18n, marketing segment, multi-tenancy belongs to this family of use cases), it's often assumed that you can't achieve personalization with static rendering, and that's just not true: a simple (read very fast, very cheap, optimized for this use case, like CDN are supposed to be) URL rewriting server can point to the right statically rendered page at request time. Another approach is modifying the page at the edge, Eleventy does that. All this involve being aware that your static content will be accessed using an HTTP request, taking that into account may lead to a more unified (not squashed though, just unified) SSR/SSG architecture similar to Next 13 one. You can look for Plasmic take on AB tests with Next or my own work on Segmented Rendering or the "megaparam" pattern.