Traditional vs headless CMS

Listen in Italian on Apple Podcasts, Spotify or Google Podcasts

Sergio: Welcome to the Moze podcast, a space for dialogue and technical insight into the development of new digital products. I am Sergio, partner of the studio, and with me today are Giacomo and Andrea, developers at Moze. Hello guys.

Giacomo and Andrea: Hello everyone.

Sergio: Traditionally, CMS software is designed to accommodate both the data level (database) and the presentation level (theme). This is the case with traditional development using WordPress or Shopify. For some time there has also been talk of headless CMS: this refers to an architectural model where the Content Management System exposes data and functionality through an API or an SDK. The CMS therefore does not deal with how this data is presented. On the other hand there is a website or a web or mobile app designed to present this data. In the Jamstack model, in particular, information is pre-generated (pre-rendered). In the case of a website or web app, html files are generated, that is, without finding the information on every request through a server-side language and a database. These two principles, respectively pre-rendering and decoupling (separation of concerns) are the foundations of this architectural approach. Giacomo, in short – what changes?

Giacomo: The benefits are faster response times (better performance), greater security by design (thanks to the fact that there is no exposed database) but above all the possibility of building a complex application which, for example, retrieves data from multiple sources in addition to the CMS, a corporate CRM or other API endpoints. 

Sergio: What tools can be used?

Giacomo: On the CMS side, there are some “natural” headless solutions, such as Strapi or Sanity (CMS). However, you can use things like WordPress in headless mode. Front-end there are options like Next.js or Gatsby — but there’s nothing stopping us from adopting custom solutions; it depends on what you need. In general, using frameworks already designed for this type of solution greatly simplifies the work of our developers.

Sergio: Let’s talk about our experience: Sanity, Next.js, Vercel. What is Sanity? What are the benefits compared to a traditional CMS like WordPress?

Andrea: Sanity is a service that provides a cloud database and an open source CMS called Sanity Studio. The unique aspect of Sanity Studio is that it is based on React, thus allowing us, the developers, to freely create new components that will then form the interface for content management. We can also install plugins, made available by the community, or create them from scratch.

Sergio: The content editor is therefore completely customisable, correct?

Andrea: Exactly. To increase the level of customisation, Sanity Studio, in addition to the components supplied by default, offers the possibility of creating new ones: the so-called custom input components. These are nothing more than React components used, for example, to create custom interfaces, retrieve data from third-party APIs, or show previews directly in the input field, helping to greatly improve the user experience of those who are using the CMS. Sanity also simplifies the creation of the components by providing a library (Sanity UI) with ready-to-use elements (buttons, select, card etc…) and methods (e.g. PatchEvent API) to be able to write directly to the Sanity dataset in a very simple way.

Sergio: In practice, if a CMS has to interface with third-party data, perhaps in a cloud service, Sanity may be the right solution because it allows full customisation of the content management process, and is able to compose the interface and the logic of finding data as necessary. Giacomo, why React? What is Next.js and what are the benefits in the headless context?

Giacomo: React is a rendering library developed by Facebook and adopted by the community that has extended its functionality with many npm packages (i.e. libraries and ready-to-use components). Next.js is a framework based on React, which provides developers with work tools to facilitate, for example, the management of routing or fetching information. It is a “plug and play” solution that does not require special configurations if all you need is a standard solution. It provides us with tools such as pre-fetch, static pre-rendering or server-side pre-rendering. 

Sergio: What is the difference between these rendering methods?

Giacomo: Static generation occurs at build time; when we deploy our site, the data is requested at the source (which could be an API or a specific file) and is literally written (injected) into the html. So, when the user asks for the page again, no server-side calls will be made to find that data. The running of the page is therefore immediate and reduces the risk of database exposure to zero, since no external call is being made to retrieve the data.
This, in addition to greatly improving performance, also reduces costs because, as there is no server-side processing, what is served is essentially a static file: easier to distribute also through CDN services that allow the spread on a global scale.
The server-side rendering, however, works in a slightly different way: when the user lands on the page, this is requested from the server with specific parameters (perhaps dynamic, e.g. the ID of a product in e-commerce). The server will call an API to find the information based on the parameter that is requested, build (then write the specific information of that page in the static html file) that specific request and serve the static file to the user. This technique is necessary when you need to index the content of a page with dynamic data.

Sergio: Otherwise there would be the risk of making the contents indexable.

Giacomo: Exactly. Next.js provides very simple tools to achieve this result and also allows a hybrid use of the same tools: it is possible, in fact, to specify the type of pre-rendering to be used on the individual pages.

Sergio: Thank you Giacomo. Andrea, what is Vercel? And what makes it interesting?

Andrea: Vercel is a platform suitable for deploying front-end applications developed with frameworks (such as React or Next.js) and static sites. It marries perfectly with Next.js created by Vercel developers. The ability to directly connect the repository to the platform makes it particularly easy for the development team to deploy the application. We found the “Preview” feature very useful; it allows you to quickly see the result of any contribution to the source code, even on branches other than the main ones. With Vercel, you can also make use of serverless functions. This is an architectural paradigm in which certain portions of code are executed by a Cloud provider, avoiding the main problems of setup, deployment and server management. We have experienced this functionality both in Next.js, in a very simple way thanks to the pre-configuration of the same framework for this type of service, delegating certain tasks to the serverless functions of Vercel (for example the generation of PDFs) and in Sanity Studio, the ability to view changes made to a page in real time, improving the experience of editors.

Sergio: Thank you Andrea. Giacomo, when should you choose headless? And when should you opt for a more traditional solution? 

Giacomo: This depends on the project. If we talk about custom applications, a design choice of this type does not exclude the possibility of using more traditional approaches in the development of applications. For example, I could have parts of my application with static pre-rendering, parts with server-side rendering and in both parts I could have real-time API calls. This depends on the goal you want to achieve. Choosing headless means you can provide content that can be used substantially by any client, device, and language. This flexibility allows you to make the most suitable technological decisions for the type of application of each situation. An example is when you have to develop a digital product with a web client and a mobile one. In this sense, a headless solution is agnostic with respect to the type of front-end and is limited to delivering content in the form of APIs, allowing developers to freely decide which tools and frameworks to use to display content. This choice can make it easier to decide to change the content management platform later, but above all it improves the scalability of the project, especially when the client that uses it is a JavaScript application such as an application based on Next.

Sergio: Thank you Giacomo and Andrea. Today we talked about headless, Jamstack and why to use these new paradigms. We’re curious to know about your experience. Feel free to write us at www.mozestudio.com. Thanks!

Giacomo e Andrea: Ciao!