Headless CMS explained in 5 effective minutes
Storyblok is the first headless CMS that works for developers & marketers alike.
This article will cover the basics of what a headless CMS actually is. You will learn about the main differences between a headless CMS (eg. Storyblok, Contentful, Prismic, ...) - and a more traditional (monolithic) CMS like Adobe Experience Manager, Sitecore, Drupal, and Wordpress.
Why would you need a headless CMS?
Nowadays, managing textual, structured, multimedia content also implies being able to then distribute it on different platforms can be the Web, e-commerce, mobile applications, personal devices such as smartwatches, or digital signage systems in stores or malls.
In addition, the content can be personalized according to the user, his location, language, behaviors, and preferences. For this reason, today more than yesterday, content must be somewhat untethered and as independent as possible from who can enjoy it and the medium by which it is enjoyed. Making the content management independent as much as possible from the distribution medium means having to implement solutions in which the information management part (the CMS) is decoupled from the frontend part. CMSs that deal "only" with the content management part are called Headless CMSs.
So the CMS part is focused on content functionalities like managing content for: structure, reusable components, presets, versioning, collaboration, workflow stages, roles and permissions, publishing policy, preview, backup, security, reliability and so on.
Decoupling the frontend and the content management part means that the development team can choose their own stack, without restrictions or special requirements coming from the CMS part, and can focus only on the UX and UI, reducing the time to market and the costs. How much does it cost a team (developers, project managers, DevOps engineers, quality assurance specialists that design, build, deliver, and maintain yet another new CMS?
What is a headless CMS?
A headless CMS is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API or GraphQL API for display on any device.
The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository). A headless CMS remains with an interface to manage content and a RESTful or GraphQL API to deliver content wherever you need it. Due to this approach, a headless CMS does not care about how and where your content gets displayed. It only has one focus: storing and delivering structured content and allowing content editors to collaborate on new content.
Let's have a look at a Monolithic CMS and its feature set:
A database for the content to read and write to.
An admin interface to let editors manage the content.
An integration of reading and writing.
The actual front-end that combines the data from the database with HTML.
To convert that into a headless CMS we remove the templating feature (4.) from the stack as that is the head of that CMS - the actual website. With that done, we can replace it with a RESTful or GraphQL API that is accessible by other systems to access the data that was managed in the Admin UI. Et voilà: you now have got yourself a headless CMS.
Other than by using a regular/monolithic CMS, a website can't be built only with a headless CMS. A headless CMS separated the head from its stack and therefore lacks this point by design. Therefore, the developer must craft the website by themselves and use the provided REST or GraphQL APIs of the headless CMS to access the content.
Creating the whole website on their own seems like a big task on the list, but by decoupling the CMS from the front-end a developer can choose any technology they are already familiar with and do not need to learn the technology for that specific CMS.
Another big bonus is the fact that one developer can also focus on their own work without handling the bugs of an already existing stack of technology - therefore it is easier to optimize pages for pagespeed and webvitals and even relaunch parts of the website or make breaking technology decision without worrying about losing the existing content.
Do I need a headless CMS?
The answer to this question is quite simple, but it won’t help you much right away: It depends on your requirements. There are use cases where one CMS outstands the other and vice versa. To help you decide, let’s have a look at the benefits really quick:
|Traditional CMS||Headless CMS|
|Replaceable technology stack||-||Yes|
|API first approach||-||Yes|
Use cases for Headless CMS
Separating your content from the tech stack of your website to be able to move faster.
Websites created with static site generators such as Jekyll, Gatsby, Middleman, or Hugo.
Use it for feature flags of your own product to schedule releases of new features.
As a configuration interface for your home automation solution.
Or to manage content for your intranet.
Point is: It is not limited to websites
A headless CMS can deliver your content through an API directly to where you need it. Because of the headless approach the content can be used on an iOS app, Android app as well as any platform and technology you can think of and is therefore a powerful option for mobile and web developers.
Headless CMS Options
In an earlier article we wrote about how WordPress and Drupal already trying to work their way to at least offering an API approach. Both of these options try to make the CMS work in a way that they were not initially designed for. Here are some headless CMS options you might like to have a look at to find your best fit: Storyblok, Contentful, Prismic, Sanity. There are also other options out there, but looking at the features and concepts - those are the platforms you should have a look at.
Storyblok: Headless CMS
Storyblok has its main focus on the API including the overall performance, querying capabilities, nested components, documentation, consistent support, and upgrades. Storyblok provides clean and structured JSON for developers mixed with services like:
Choose your own technology to get started from our technologies overview page.
As you see there is no 100% right way and CMS for every use case - but we think that chopping off the presentation layer of your content and making it accessible for more than just one platform if needed is the approach we should aim for! Not just to reuse your content more easily, but if you ever want to change your technology stack you don't have to worry about your content.
Ready to get started?
Our team is more than happy to help you with your transition to a headless CMS.