Content Website with Next.js and Storyblok

Lorenzo GM
Valtech Switzerland
5 min readNov 23, 2021

In this article I’m going to describe our journey building a content website with the following technology stack:

  • Front-end: React with Next.js
  • Back-end: Not required :)
  • Headless CMS: Storyblok
  • Infrastructure: Vercel and Github

A quick summary about how it works: the front-end application fetches the data from the Storyblok and renders the content. The repository is hosted on GitHub and deployed to Vercel.

Repository: https://github.com/lorenzogm/ring

Features

Let’s start defining the expected features of this website:

  • Product based website with stories, news and products.
  • Internationalisation with the option of unlimited languages.
  • Content is created and maintained centrally and it’s highly structured.
  • Content could contain small modifications for different languages or completely filtered for specific markets/divisions.
  • Visual editor to create content while browsing.

To present those features we are going to create the following content:

  • The same home page in three languages: demo.
  • One product which is similar for the three languages, only with small modifications: demo.
  • Another product which is available for only two languages: demo

Internationalisation

There are two options when structuring the content:

  • Field level structure is a good choice if the structure of your content in a different language is the same as in your default language.
  • Folder level structure is preferable when the content for different languages is managed by separate teams or your project is structured differently for each market.

Rendering

How we render our website site is one of the most important decisions when we are designing the architecture. There are several options to render it:

  • Client Side Rendering (CSR)
  • Server Side Rendering (SSR)
  • Static Site Generation (SSG)

The three of them have advantages and disadvantages, you can find more information about them in this article: Rendering on the web

Now, let’s focus on the selected architecture, which is a mix of Server side rendering and static site generation. It’s a feature provided by Next.js and Vercel called Incremental Static Regeneration. We are running a Node.js server and it’s doing the following:

  • Some pages can be generated at build time (SSG).
  • Other pages are generated on runtime (SSR).
  • All the pages are cached, we can define how much time they are cached.
  • The first request after the cache is stale, it returns the cached page (stale content) and the new one is regenerated.

With this architecture, we get the best of the Static Site Generation and Server Side Rendering. As there are two variables that we can control: number of pages generated at build time and time to cache the page (each page can have a different value). How those variables affect the performance of our website?

  • The number of pages generated on build time would impact the time required to deploy new code to our server. That’s important because it would impact i.e. how fast we can react to deploy hotfixes or the Quality Assurance (QA) process.
  • The time each page is cached would impact the performance of the website, very important for the User Experience (UX) and workload required by the server to generate pages more/less often. In addition, it needs to call the CMS every time we generate a page. Therefore it’s going to impact the infrastructure cost.
Infrastructure overview

That was the high level overview, now it’s time to have fun with all the details about the Incremental Static Regeneration (ISR) which works in the Node.js server provided by Vercel:

How rendering works in Next.js

Continuous Integration and Continuous Delivery (CI/CD)

There are no doubts that CI/CD is a must on a software project. The setup for this project involve GitHub, Vercel and Storyblok:

  • Changes in the code (in the GitHub repository) triggers a new deployment on Vercel to create a new Serverless Function.
  • Based on the branch where we have the changes, a different Serverless Function is deployed. So we can have the main functions running (PROD, TEST and DEV) and preview functions per branch, which helps the QA process.
  • Depending on the rendering strategy (detailed in the section above) we can make requests to the CMS on build time.
CI/CD

Infrastructure

As it’s a factor that could determine if a project should be done with this architecture, let’s estimate the infrastructure costs.

Vercel

https://vercel.com/pricing

We need to, at least, start with the Pro plan, because it’s required for a commercial usage. Let’s try to summarise their pricing:

  • 20 USD/month per member
  • Bandwidth: 1TB
  • Image Optimisation: 5,000 (then 9 USD per 1,000)
  • Build Execution: 24,000 minutes
  • Concurrent builds: 1 (Then 50 USD each)
  • Unlimited previewers
  • Deployments per day: 3'000
  • Domains per project: 50
  • HTTPS/SSL by default
  • DDos Mitigation
  • Password protected previews: 150 USD/month (Per team, not per project)

Other relevant features only available in the enterprise plan:

  • Custom firewall rules
  • SSO Protected Previews
  • SLA for 99.99% Uptime
  • Dedicated Customer Success Engineer

Is this Pro plan enough for your project? No idea :) I don’t even know if it’s enough for my project, I should update this section (or create a new article) in the future if I’m able to collect some data about bandwidth, build execution, etc. And definitely we need to research what’s the price for the Enterprise plan, because SLA 99.99% Uptime is only guaranteed in the that plan.

Storyblok

In this case, there are many features which depend on the project. For the features described at the beginning of this article, even the free tier could be enough.

Let’s analyse the relevant data for our infrastructure:

Community Plan

  • Free with seats for 1 user
  • Monthly Traffic included: 250GB/month
  • Additional traffic is 190€/month for 1 TB.
  • API Requests per month: 1,000,000
  • Preview deployments: 2
  • Activity logs

Entry Plan

  • 90€/month with seats for 5 users
  • Monthly Traffic included: 500GB/month
  • API Requests per month: 3,000,000

Teams Plan

  • 411€/month with seats for 10 users
  • Monthly Traffic included: 1TB/month
  • API Requests per month: 10,000,000
  • 97% Uptime SLA
  • S3 Backups & Restore

Entreprise Plan

  • 2999€/month with seats for 30 users
  • Monthly Traffic included: 3TB/month
  • API Requests per month: Unlimited
  • 99.9% Uptime SLA
  • Restricted IP address range
  • Extended Activity Log
  • Organisational Analytics

With Storybook, the situation is similar to Vercel: a lot could be done with the free plan, and upgrading the plan is still affordable.

Conclusion

This stack is a simple and affordable solution when the features available in Storybook are enough. A more detailed analysis on the available features, mainly on areas like marketing or analytics, would be required to compare it with others Content Management Systems.

--

--