Recently I was giving a talk to a group of wonderful people about the importance of headless development in general and for Sitecore in particular, compared to the old way of doing things with ASPNET MVC.
This article will be helpful to marketing people and those on the development side who somehow managed to miss out on the evolution Sitecore flagship product took in the last couple of years.
Evolution of Web Development
Before actually discussing the subject, let’s quickly recap the evolution of the web in terms of content as it was generated and served.
In the early days of the web, web development was focused on creating websites using static HTML. These websites were essentially digital brochures that provided information about a business or organization but were relatively simple in terms of both design and functionality.
As the internet grew, the demand for more visually appealing websites increased. This led to the development of CSS (Cascading Style Sheets), which allowed developers to add styling and layout to their websites. JavaScript was also introduced, which allowed developers to create interactive and dynamic elements on websites. However, these technologies were still primarily used to create static frontends, with minimal backend functionality.
As the internet became more mainstream, the demand for more dynamic and interactive websites increased. This led to the development of server-side technologies like PHP and ASP, which allowed developers to create websites that could display different content based on user input or other variables.
With time, the internet turned mainstream, and for organizations, it became increasingly difficult to manage and update ever-growing volumes of content on their websites manually. This led to the development of content management systems (CMS) like WordPress, Joomla, and Drupal, which allow non-technical users to easily create, edit, and publish content on their websites.
As web applications became further more complex, the demand for distributed backend architectures increased. This allowed developers to break up their applications into smaller, modular components that could be developed, deployed, and scaled independently.
Further ahead with the growth of cloud virtualization, it became possible to host web applications and services in the cloud, rather than on physical servers. This made it easier and more cost-effective for organizations to host and manage their web applications, as they didn’t have to worry about the underlying infrastructure.
Later the concept of microservices emerged as the result of the growth of distributed architectures and cloud computing. This involved breaking up web applications into smaller, independent services that can be developed, deployed, and scaled independently.
With the proliferation of mobile devices, it became increasingly important for websites to be able to adapt to different screen sizes and resolutions. This led to the development of responsive design, which allows websites to automatically adjust their layout and content to fit the device they’re being viewed on.
JavaScript frameworks, SPA (single-page applications), and React: JavaScript frameworks like React, Angular, and Vue have emerged in recent years, which make it easier for developers to build complex web applications. These frameworks have also enabled the development of SPAs, which are web applications that load all of their content and resources upfront, and then update the page dynamically as the user interacts with the app.
Jamstack is a modern web development architecture that involves storing static assets (like HTML, CSS, and JavaScript files) at a content delivery network (CDN) and using serverless functions to build dynamic functionality. Next.js is a framework built on top of React that makes it easier to build Jamstack applications.
Having the above in place, Next.js became a game changer for headless development with Sitecore because it provides a range of features and capabilities that can help to improve the performance, scalability, and ease of deployment of headless applications. By leveraging the power of Next.js, developers can build highly-performant and scalable headless applications with Sitecore that can deliver a seamless and engaging user experience to their customers.
So, what is Headless then?
In web development, “Headless” refers to the practice of building a website or web application without a graphical user interface (GUI). In a traditional web development setup, the GUI is provided by a web browser that displays the content and user interface elements of the website or application to the user. In a headless setup, the GUI is removed, and the website or application is accessed and controlled through an application programming interface (API) instead.
I would also recommend reading about 5 Common Questions about Sitecore and Headless Content Management Systems answered by my colleague David San Filippo.
I personally find it ironic that we came back to the origins – a static HTML served back to the browser. Of course, on the other side, it is backed by a powerful framework that efficiently takes data from the heavily distributed systems, running in containers and orchestrated by Kubernetes, which itself is controlled by infrastructure-as-code tools, such as Terraform and Ansible. But at the end of the day, the exercise remains exactly the same as it was three decades ago – to deliver an HTML page to a browser in the most efficient manner.
But what about Sitecore?
Initially, a basic product with an “everything is an item” philosophy, Sitecore quickly grew into a powerful CMS in just a few years. Further growing with features, it also improved its architectural evolution from on-prem to IaaS, followed by Azure PaaS. Then containerized orchestrated hosting was introduced as Docker containers became a de facto standard for web development. And eventually in 2022 Sitecore announced its latest Software as a Service (SaaS) offering of XM Cloud – a “composable” evolution of the XP product. Notably, XM Cloud only supports headless development and needs to be run locally using Docker containers.
Why SaaS?
There are three primary and a bunch of secondary reasons.
Initially, Sitecore sold perpetual licenses, which basically means once you bought it you can in theory use the Sitecore platform indefinitely, as long as they remain in compliance with the terms and conditions of the license. This means that organizations can use the Sitecore platform for as long as they want, without the need to renew their license, however, occasionally they do need to pay additional fees for support and access to the newest features.
With the scalability benefits of virtualization, Sitecore started offering subscription licenses which are a type of license that allows organizations to use the Sitecore platform on a pay-per-use basis. This allows organizations only pay for the resources and services that they consume, rather than purchasing a perpetual license upfront. Infrastructure however still remains in the control and responsibility of the organization using it.
With XM Cloud introduction, Sitecore brought a pure SaaS model. Sitecore keeps full control over both platform and underlying infrastructure, leaving most of the development to the “head” part of it. In addition, it resolves certain points of pain the platform previously suffered from including:
- Platform upgrades are one of the time-consuming and uncertain activities that eat out a significant budget, but on their own bring very little of new features. I have written a decent series of blog posts exclusively devoted to the Sitecore platform upgrades and the accompanying complexities. With SaaS model that issue has totally gone.
- Infrastructure management and maintenance, security maintenance, taking care of scalability – all that was previously done by the Sitecore clients now is fully managed by Sitecore
- A bottleneck of Sitecore developers. Lack of availability of Sitecore developers may encounter a staffing bottleneck when building and maintaining Sitecore-based applications, including the complexity of the platform, limited documentation, dependence on the Sitecore support team, and limited resources. On the opposite, developing “head” requires generic frontend skills that are much easier to come by.
- Platform architectural bottleneck. In addition to the above, scaling up your (typical bottleneck) CD servers in a non-headless environment comes at a cost compared to XM Cloud which does not have CDs but only serves content via highly available APIs endpoints.
That results in a drastically improved development process, velocity, and reliability. Now, once we recap the evolution of both internet in general and Sitecore in particular, let’s get back to:
Headless with Sitecore
It is clear that Sitecore prioritizes a headless approach over all the other types of development for the reasons described above. In my opinion, this transition should ideally have taken place 1-2 years earlier, but I do realize XP product has grown so much in features, that it would not be easy to migrate its entire functionality to headless.
The transition to headless development brought us lots of new terminology and concepts which I will explain below. As we already know, headless itself is decoupling the frontend (“head”) and backend: By separating the GUI from the underlying logic and data, it becomes easier to develop and maintain the different parts of the website or application independently. This can be especially useful when different teams are responsible for different parts of the project, with Sitecore developers doing back-end stuff providing data and layout to a front-end team, who is responsible for the development of pages and components that will run on the Rendering Host..
A Rendering Host is a separate website mostly often created with Next.js and Node (however could be also a device or system) that is responsible for displaying the content of a website or web application built with Sitecore. This can be particularly useful when building a frontend application that needs to display content from multiple sources, or when using a framework or technology that is not supported by the CD server.
The rendering host retrieves the content from the Sitecore database by API and displays it to the user. The rendering host also plays a key role in the performance and user experience of the website or application and can be scaled independently, which significantly improves the bandwidth bottleneck of a classical Sitecore implementation we historically had with MVC running at CD server.
From CD to Edge
In a traditional, monolithic implementation of Sitecore, the Content Delivery (CD) server is responsible for both rendering and delivering the content of the website to users. In a headless implementation, the frontend application is decoupled from the backend CMS, and the CD server is not responsible for rendering the page content which now becomes a business of the Rendering Host. CD instead mostly serves the data in json format from Sitecore to Rendering Host using API requests. So, if the CD server becomes less important, could we then entirely remove it from the architecture?
The answer is yes, and this solution is called Sitecore Experience Edge – a content delivery network (CDN) that allows faster delivery of content and results in improved performance of websites and web applications. One advantage of removing the CD server in a headless implementation of Sitecore is that it allows for more flexibility and control over the frontend (head) application. In addition, removing the CD server can improve the performance and scalability of the frontend application as without the need to communicate with the CD, the frontend application can retrieve content directly from the Sitecore Edge API, which is typically faster and more efficient. This can be particularly useful for applications with high levels of traffic or concurrency.
However, removing CD server can reduce the ability to personalize and optimize content for individual users as well as dealing with secured content. In a traditional, monolithic implementation of Sitecore, the CD server is responsible for rendering and delivering the content of the website to users, and it has access to user-specific data like visitor profiles, goals, and interactions. This allows the CD server to personalize and optimize the content of the website based on individual user behavior.
In a headless implementation, the frontend application is decoupled from the backend CMS does not have direct access to user-specific data like visitor profiles, goals, and interactions, therefore on its own it cannot personalize and optimize the content of the website based on individual user behavior.
To work around this disadvantage, it may be necessary to implement personalization and optimization capabilities in the frontend application or to use a separate tool to manage this functionality, such as CDP and Personalize or Optimizely. This requires additional development and integration efforts, however, it brings all the benefits of a truly decoupled architecture.
GraphQL
In a headless implementation of Sitecore, Sitecore Experience Edge uses GraphQL query language to provide specific data and exactly what data it needs, rather than receiving a fixed set of data from the server as in a traditional REST API. This can be particularly useful when building a frontend application that needs to display content from multiple sources, as it allows the client to retrieve only the required data, rather than receiving a large payload of data that may contain unnecessary information, improving the overall performance of the application.
Next.js
Historically Sitecore JSS (which is the legacy name of Sitecore Headless Services) supported three main JS frameworks – React, Vue and Angular. All three struggled from classical SPA architectural disadvantages, such as lack of server-side rendering, resulting in poor SEO ranking, clumsy codebases making it harder to maintain the code for larger apps, routing issues etc.
Since React was the mostly used framework, it was always the first to get support. Therefore Next.js was picked as a preferred technology to eliminate the mentioned functional gaps since it was actually built using React.
Next.js is a popular JavaScript framework that is often used to build server-rendered React applications. When used in conjunction with a headless implementation of Sitecore, Next.js can provide several benefits, including:
- Server-side rendering (SSR): One of the main advantages of using Next.js with Sitecore headless is that it allows for server-side rendering of the frontend application. This means that the application is rendered on the server before being sent to the client, which can improve the performance and SEO of the application.
- Static Site Generation (SSG): The powerful mode aimed to reduce the amount of time for a request by serving a fully pre-rendered HTML page, rather than a blank page that is then filled in by JavaScript. This can be a good option for sites that don’t require frequent updates or for sites that don’t have a lot of dynamic content.
- Incremental Static Regeneration (ISR) is a mode to improve the performance of your application by re-generating and deploying only the pages that have changed since the last build. In one of my blog posts, I described in detail how this mode works and why can be especially useful if your application has a large number of pages that don’t change very frequently.
- Automatic code splitting: Next.js automatically splits the code of the application into smaller chunks, which can help improve the performance and loading times of the application.
- Automatic optimization: Next.js includes a number of built-in optimization features, such as automatic compression and minification of assets, which can help improve the performance of the application.
- Easy deployment: Next.js includes a built-in static file generator, which makes it easy to deploy the application to a static hosting service like Netlify or GitHub Pages.
But not just that, Vercel – a company that stands behind Next.js, is also a cloud platform provider for hosting applications and websites with its globally distributed CDN network. Some advantages of using Vercel for hosting include:
- Easy deployment: Vercel makes it easy to deploy applications and websites with features like automatic builds and deployments from Git repositories, and a simple command-line interface for manual deployments.
- Global CDN: Vercel uses a global content delivery network (CDN) to deliver content to users quickly and efficiently, regardless of their location.
- Scalability: Vercel’s infrastructure is designed to handle traffic spikes and handle high levels of concurrency, making it a good choice for applications with unpredictable or rapidly growing traffic.
- Custom domains: Vercel allows you to use custom domains for your applications and websites, making it easy to use your own branding and create a professional-looking online presence.
- Integration with popular tools: Vercel integrates with popular tools and services like GitHub, GitLab, and Bitbucket, making it easy to use with your existing workflow.
- Security: Vercel takes security seriously, with features like automatic SSL certificates, DDoS protection, and intrusion detection to keep your application and data safe.
Once you have set up your Vercel account and configured your Sitecore application, you can use Vercel’s hosting and tools to build and deploy your front-end application with lots of useful features, including Git integration, continuous integration and delivery (CI/CD), monitoring, and custom build and deployment scripts. Last but not least to mention – it nicely fits the rest of the Sitecore ecosystem
To conclude, Headless Development with Sitecore becomes the primary approach for 2023 due to its numerous advantages and mature set of tools, as it improves processes, productivity, and performance at all stages and will be ever-growing.
