Server-side rendering simplified
SSR stands for Server-side Rendering. I’ve worked with next.js, gatsby SSR, and nuxt.js widely yet when it comes to discussion on interviews I end up staying less confident for some reason. Since the learning curve is low, most of us would have jumped right in without researching about the why part 🌜 — at least me 😟
One fundamental question I used to get in almost all the interviews is,
For your app, how do you arrive at whether or not to use Server-side Rendering?
Take a pause, try to answer, and if you feel like not cliffing much — then this short article could interest you.
What is Server-side Rendering?
So what is server-side rendering? Let me not bore you with so common definitions. Server-side Rendering is simply you request a server for some HTML page (probably with a link like https://mywebsite.com/mypage) and the server serves the HTML page (probably with some headers associated) for you that the browser can process.
Simply you could think of client-side rendering like building your house from the ground up while Server-side rendering is like buying a pre-build furnished house and moving in.
Uhm, that could sound naive — this is not a precise one, SSR does a lot yet should be a good start though.
Let me quickly show you in a diagrammatic way how client-side SPA rendering and server-side SPA rendering works just to hop on the leap.
Typical Client-side Rendering — SPA (could be your React/Vue app)
Server-side rendering — SPA
Hope the above diagrams are self-explanatory. Let’s explore the other parts :)
Universal Apps
Now comes the next question, which one to pick — CSR or SSR?
Well, we can actually make use of both. Know how? Those are termed universal apps (next.js, nuxt.js, gatsby makes it easier). In a Universal Web App, the initial render will be done in the server, and once the page loads client-side rendering will take over. This makes sure that we have good SEO, a quick first render, and speed when browsing in the app. Still, it’s the developer's choice to go with desired fashion answering what the application demands.
Trade-offs to consider when using SSR
Development constraints
You might have encountered errors like window is not defined if you’ve already worked with any of the above SSR frameworks. This is because browser-specific code can only be used inside certain lifecycle hooks; some external libraries may need special treatment to be able to run in a server-rendered app.
Build setup and deployment requirements
A server-rendered app requires an environment where a Node.js server can run.
More server-side load
Thus comes the server-side load, Rendering a full app in Node.js is going to be more CPU-intensive than just serving static files. Thus it’s obvious to be prepared for corresponding loads in advance.
Finally, should you be using it for your next app? To answer this, I would like to quote the paraphrase from new vue docs,
Before using SSR for your app, the first question you should ask is whether you actually need it. It mostly depends on how important time-to-content is for your app. For example, if you are building an internal dashboard where an extra few hundred milliseconds on initial load doesn’t matter that much, SSR would be an overkill. However, in cases where time-to-content is absolutely critical, SSR can help you achieve the best possible initial load performance.
You can read more about it on https://vuejs.org/guide/scaling-up/ssr.html
If you have any suggestions (as I’m new to this) or wish to discuss more on this topic please write to me at mariappangameo@gmail.com. I’d also love to connect with you all on Linkedin.
