One on the most important decisions that will affect the architecture is how we render the content. This decision will affect several outstanding metrics to take into consideration, some of them are:

The purpose of this article is to analyse the existing types of rendering for the Web to help us to make the decision.

The main three types of rendering on the web a those:

Server-Side Rendering (SSR): the page is rendered on runtime in the server in response to navigation. All logic, templating and data fetching are handled in the server.

Static Site Generation (SSG): static pages are generated on build time. All logic, templating and data fetching are handle in the server on build time.

Client-Side Rendering (CSR): the page is rendered on runtime in the the browser. All logic, templating, routing and data fetching are handled in the client.

To measure the performance we are going to pay attention to the loading process of a website:

And we are going to focus on the following metrics:

TTFB: Time to First Byte — time between clicking a link and the first bit of content coming in.

FCP: First Contentful Paint — when the requested content becomes visible.

TTI: Time To Interactive — when the page becomes interactive for the user.

With this information let’s check the summary again:

SSR: Because the page is rendered in the server, TTFB is slow, but there is no delay between TTI and FCP. The speed is fast (it depends on the resources of the server) and the UX is great because the content is ready to interact (TTI = FCP). However, SSR cannot be used with a CDN.

SSG: As the browser is rendering static pages, TTFB is fast and the delay between TTI and FCP is minimal. Therefore, the speed is fast and the UX is great. Compared to SSR, SSG has the advantage that it can be used with a CDN.

CSR: TTFB is fast but the loading time until the page is ready to interact (TTI) could be a lot, because all logic, templating and data fetching are handled in the browser. CSR can be used with a CDN to boost the performance.

The data is stale when the information displayed is not updated. This is an outstanding topic when deciding our architecture. Let’s check every case:

SSR: The page is rendered on the server on runtime. Therefore the data would be fetched with every request and it won’t be stale.

SSG: The page is rendered on the server on build time. In this case, the data could be stale. This approach could be very useful for websites where the data doesn’t change very often (like blogs), but it won’t work if the data needs to change constantly.

CSR: Similar case as the SSR. The page is rendered on the browser on runtime. So, the data would be fetched with every request.

SEO could be the key point to decide which is the right architecture for your project.

SSR: Fully-renderer pages are sent to the bots, so there is no risk of partial indexing. In addition, SSR can speed up the page load times, which can help to improve the rank in the search engine.

SSG: Fully-renderer pages are sent to the bots, so there is no risk of partial indexing. In addition, SSG can speed up the page load times (even more than SSR), which can help to improve the rank in the search engine.

CSR: The content may not be available when the search engine bot is crawling the page. So there is a risk of “partial indexing”.

The three solutions required infrastructure to handle the build and the deployment. In that case, the costs won’t change too much from one approach to the other. What we are going to evaluate is how expensive is to maintain the servers to have our website running?

SSR: This is the most expensive solution. As the page is rendered on the server, all the workload is done in the server on runtime. Therefore, we need to invest money on those servers which are constantly running.

SSG: The static pages are handled by the browser. For very large website, the build time would scale and this could affect the costs of the servers to build the application.

CSR: The browser is taking the workload, so there is no extra cost to maintain the website running.

Infrastructure setup, development of the website and maintainability of the projects are the areas to keep in mind about this topic.

It used to be that creating a website with SSR or SSG was very complex compared to CSR. However, nowadays there are many options to easily write web applications with SSR or SSG easily. Therefore, the complexity shouldn’t be a topic right now to decide which rendering type to choose.

At this point, probably the decision is made and the security (or the extra security) shouldn’t be a key topic to decide which rendering type to choose.

It’s just worth to mention that with SSG, as the page is static, it’s not connected to any server. So this is an extra layer of security with the following benefits:

Some of the most common vulnerabilities (injections and XSS) won’t affect a SSG. Attackers can’t hack you database since the website is not connected to it.

The output is pure HTML, CSS and other static files, it’s very unlikely that static content contains security vulnerabilities.

Let’s have a look to the summary of every topic discussed before to have a better overview:

And let’s match the most common projects with the most suitable technology to use. There are two main types of projects, based on the content:

Public content: When the project is a content site, probably SEO is very important. Therefore, CSR is not an option. SSG should be the way to go because it’s less expensive, more performant and it adds extra security. But it depends on how often change the data. If doesn’t change too frequently, SSG it’s the best option. However, if they data change too frequently or with every render, SSR or an hybrid solution (hydration) with SSG + SSR would be required.

Examples: Corporate Websites, Blogs, Ecommerce Shops or any other content site would some examples for this use case.

Private content: When the content is hidden behind a login, then the clear option is CSR. Because SEO is not required, the data is related to the user and it changes very often. SSR could improve the performance of the website, however the infrastructure costs and the complexity could be a huge drawbacks compared with the benefits.

Examples: Banking Apps, Social Apps or any other application behind a login.

Alright! Now we should have enough information to decide how we should build our next project.

I have written a little website with React and Next.js to demonstrate some of the ideas from this article:

Demo: https://nextjs-rendering-types-demo.vercel.app/

Source code: https://github.com/lorenzogm/nextjs-rendering-types-demo

One  on the most important decisions that will affect the architecture is  how we render the content. This decision will affect several outstanding  metrics to take into consideration, some of them are:

Rendering on the Web

How we made our project more maintainable

Maybe  this situation sounds familiar: you are a software developer and you  join a project. It’s a good match because you know the technologies and  the project itself is interesting for you. So you onboard quickly and  get comfortable contributing to the project easily..

However,  the project has been running for a while and the codebase is already  pretty big. You still don’t have an overview about the existing pages  and with every new ticket, you spend more time finding the right page,  and the right component, than the time you spend on fixing the bug,  because we all start fixing bugs when we join a project.

Ok,  now we know where is the page and we find the component with the bug.  But the bug is not there, is coming from the mother component. No  problem, let’s check it… and the mother component is somewhere else in  the huge tree of folders. Then you find out that the bug could be  related with a function defined in the “utils” folder… by now, you’ve  already lost the context of the very first component. But some time  later, you finally fix the bug. The ticket is done and you are happy.

Time  to pick the next ticket, it’s something similar to the previous one, so  it should be easy. You take your time again to find where is the code  that you are looking for and when you arrive… similar functionality done  in a completely different way. Yes, it’s normal: several developers  have been working on the project, so different ways to achieve a similar  result. Mmm, but now the folders and the files have also a different  naming convention, and a different folder structure. Anyway, you still  find the bug and you fix it. The ticket is done and you are happy,  again.

At  some point you start getting more complex tickets and the time spent to  understand what’s happening and how can you fix it keeps increasing  with the complexity. You’re beginning to realise the main pain-points of  your codebase.

Actually,  there is some structure, because someone created the “components” and  the “pages” folder, but inside of those folders… oh dear, that’s the  jungle.

Many components, not very reusable and just used once are in the “components” folder.

Something similar is happening with the chaos of the “utils” folder.

Somehow,  there was no time to setup some basic rules for the technologies used  in the project. Therefore, some “not too good” practices have been used  in the whole codebase.

Testing  is good, we all know that testing is very good and it’s very helpful,  but who has time to write test? Not me, and not the other developers who  previously worked in the project, apparently.

If  they didn’t have time to fight the previous points. Documentation about  the project is not expected at all. Or at least not related with the  main pain-points on the table.

4 steps to make our project more maintainable

We  could see how these pain-points were slowing us down and frustrating  the team, so we started taking 4 steps to fix them and make our project  more maintainable:

Define linting rules and code conventions.

Write documentation about the previous steps.

Every step will come with a detailed post providing more information about our experience.

Define a folder structure, linting rules and code conventions, write automated tests and write documentation about the previous steps.