Hi guys,
Those last 2 years, I’ve been exploring Next.js static and server-side rendering capabilities thoroughly. I am particularly interested in how to render private and personalized content, a scenario you often hit when creating SaaS applications.
For instance, you might want to render a page differently based on the language, but also on the user organization and role within the organization, preferred theme…
Most often, developers will fall back to client-side rendering or request-time server-side rendering for such contents. That’s a shame, because I think static rendering of private and customized content is actually perfectly doable in many scenarios.
I’ve written an article that describe how to do so: https://blog.vulcanjs.org/lets-bring-the-jamstack-to-saas-introducing-rainbow-rendering-ad1834fe62ff
To put it in a nutshell, if you put a gateway in front of your Jamstack app, you really unleash the power of this architecture.
However, I haven’t yet succeeded to implement this architecture with Next.js.
I am not completely satisfied with Next.js capabilities. The recent introduction of rewrites is a first good step, but it lacks a way to process requests in order to secure them. Most common scenario being checking if the user is authenticated ; Next.js provides no way to do it correctly server-side.
Now, I am trying to get an higher view of this problematic, independently of the underlying framework. That’s how I’ve ended up here at Redwood 
- What’s your opinion on such an architecture, and the possibility to handle private and personalized content in a static manner?
- Do you think this architecture could be implemented with Redwood?
PS: sorry if I post it at the wrong place, technically this article is not specific to Redwood and more focused on Next.js, which I use professionally, but I really wish to get Redwood users stance on Jamstack+personalized content
1 Like
Hey @eric-burel, welcome to the party! This is a great place to post this and I know this is a very hot topic right now in the world of web dev. @danny is our current resident expert on pre-rendering (and also has a decent amount of experience with Next), so he will likely have some thoughts about this.
This is a timely post as @Danny and I have recently begun thinking about the ways to offer this type of rendering in Redwood – or at least something similar.
This is a big topic and maybe too big for forum discussion.
But, maybe you, Danny and I can chat and see what might be possible for a proof of concept in Redwood if you are interested in that?
1 Like
@eric-burel in short, yes, we’ve had many ongoing conversations about this general topic. For us it falls under the banner of “Redwood performance at scale”. We don’t have specific solutions, but we do have a lot of ideas.
@dthyresson Please do take lead on setting up a time to connect and loop me in! Would be a pleasure to join.
Awesome I am glad that you like the subject, yeah I’d be happy to give a hand!
There are indeed a lot of possible approaches to improve the rendering of personalized/private content. I often hear about caching and CDN in combination with request-time rendering, in order to get similar benefits to pre-rendering, but dynamically (Next Incremental Static Regeneration is exactly this with filesystem as the cache).
If you like math and research papers, I’ve also wrote some formalization of ssr you could be interested in, because sadly there barely is any formal academic research on this subject.
If you like math and research papers, I’ve also wrote some formalization of ssr you could be interested in, because sadly there barely is any formal academic research on this subject.
This is amazing. I find the complete lack of actual empirical research or formal statistics employed in web development maddening, especially when so many are insisting it should be referred to as an engineering discipline. (If you want to be an engineer than you need math, sorry).
Hi guys, I’ve been working a bit more on this, and I’ve finally been able to produce a first working demo using Next.js 12 middlewares, see the blog post:
- It uses a middleware to secure content, so you can safely pre-render private content. Unallowed users won’t even be able to render the page. You can mimick this behaviour with any kind of proxy, and probably Netlify edge function, however the Next.js middlewares are nice because they are relatively easy to understand for JS devs with no devops knowledge.
- It uses an encoded root route param (good luck pronouncing that correctly :)): this part is a kind of hack to palliate the inability to pre-render different variations of the same page depending on headers and cookies, since you can only pre-render based on the route params in Next.
- It uses a rewrite to alter this route param => basically this let’s you select the right variation of your page, based on whatever param you want: current tenant in the cookies, accept-language header, whether the user is paid or not etc. Rewriting avoids bloating the URL, yet let’s use use Next.js route params to select the right pre-rendered content.
This pattern is equivalent to using a cache intelligently with request-time SSR. However, it is probably easier to understand for non-devops frontend and full-stack developers, because everything happens in JS, using roughly 30 lines of JavaScript code.
I’ve also slightly updated my SSR formalization that I’ve shared earlier: https://tinyurl.com/ssr-theory
You can skip to the end of this page for a generalized API for SSR: it encompass all existing server-side rendering patterns, whether build-time, request-time or incremental.
The remainder of the paper is just a list of hypothesis to guarantee that your build-time will finish (basically that you have a finite number of variations for a page).
Hope you’ll like and that it could be inspiring for Redwood!