You’ve probably seen the term “headless” used countlessly over and over again. There are so many platforms, services, and frameworks that use a headless architecture. An example of this is Medusa, a headless commerce platform.
But what is headless, really? And why is it becoming a trend?
In this article, I’ll simplify the meaning of “headless” as much as possible. I’ll also go over some of the benefits of headless architecture and some of the popular headless trends.
What is Headless
The formal explanation of a Headless architecture is the decoupling of the frontend and the backend. But what does that actually mean?
Real-life Example
Let’s take PlayStation (or any other console you prefer) as an example. When you buy a PlayStation, you buy the console or device that allows you to play games, handles your storage and settings, and more.
However, you’re free to connect it to whatever monitor or TV you want. You just need the correct cable that works for both your monitor and PlayStation, and you’ll be able to see the games and play them.
A headless server is the PlayStation console in this example. It holds all logic needed to perform certain functionalities and store and manage data. That’s its main focus. It’s not concerned with how these functionalities and data are presented to the user.
A headless server then exposes a set of APIs to get access to the server’s functionalities and data. Think of the APIs like the HDMI port in a PlayStation.
The APIs are designed in a way that’s optimal for the server. It’s not concerned with who or what is using them. Those who want to use it will simply have to follow its design to allow the user to perform the functionalities provided by the server or present data to the user.
What it Really Means
Traditional monolithic architecture tightly binds the frontend to the backend. This means that any backend decision can affect or be limited by the frontend, and vice-versa.
The headless architecture removes the binding between the two components. A backend should focus on processing and handling logic and data only. It’s concern shouldn’t be how to present it to the user.
Similarly, the frontend should focus on how to provide a good web design and user experience. It should allow the user to be able to perform a set of functionalities and interact with the data in an intuitive way.
This separation can be done by making sure the backend exposes well-designed APIs that the frontend can use to provide an graphical interface to the user. Whether the frontend is a website or an app, it should be able to access the backend just the same.
Why Use a Headless Architecture
A headless architecture provides a lot of advantages for both the backend and frontend. To keep it simple here are some advantages for each:
Backend
- You have more freedom in designing APIs or the internal architecture and logic. This removes a lot of hacky solutions that developers used to run into previously.
- Your backend will be more scalable and you can integrate it with third-party services hassle-free.
- Your backend is more secure as the user will be interacting with the frontend and as the backend and frontend are generally hosted separately.
Frontend
- You have more freedom in what framework, device, or programming language you use. You can use frameworks like Gatsby to create faster static websites.
- You can focus on the design and user experience of the front end without being weighed down by the backend.
- You can reduce costs on hosting your frontend as there are more flexible solutions for the frontend on its own rather than a tightly-knit frontend and backend.
Popular Headless Trends Explained
Currently, the most popular headless trends are headless Content Management Systems (CMS) and headless commerce.
These 2 concepts are gaining popularity as they bring so much power to developers and systems as a whole.
Headless CMS
A headless CMS is a CMS that allows you to manage content without worrying about how or what is going to present the content. This allows you to integrate CMS into any system or website of your own just by calling the APIs that the headless CMS exposes. An example of this is Strapi or Contentful.
Headless Commerce
Headless commerce is a platform that provides all basic checkout functionalities through its APIs. You can then build the storefront that the user interacts with using any framework you want or for any device. An example of this is Medusa.
You can also seamlessly integrate a headless CMS like Strapi with a headless Commerce like Medusa for an ecommerce platform with rich CMS features.
Conclusion
A headless architecture leads to a better developer experience, highly scalable applications, and better performant websites. Headless will only get more popular with time, and it's important you get a better understanding of it.
If you’re interested in getting started with headless commerce, check out Medusa’s Quickstart guide to get started in minutes.
Top comments (18)
Good analogy
Thank you!
Very simple explanation here. Love it!
Great explanation!
Thanks!
I imagine non-headless sites, like for example Shopify and Shopify themes, as a Nintendo Switch in this analogy. The storefront api of course is by shopify and is headless.
That’s another good analogy!
Too simplistic but nice term.
The best headlessCMS I have used is Directus directus.io/
I tried to use Strapi and followed many of their tutorials but never got a working product.
After playing with Directus I have one localhost installation for testing and playing around with the GUI.
I have another hosted on Supabase for additional testing and using a live API service.
And another fully hosted on DigitalOcean for my clients that allows them to make edits to their sites in real-time.
They deserve more credit for an amazing product. Strapi was a pain to even get started.
We have love for all open source projects! I’m sure both have good use cases in their own right
Thank you for the article, I liked the analogy. It would be cool to mention Nintendo switch as a not headless console :)
One question: what's the difference between the brand new headless architecture and the old and boring client-server architecture?
Yes the Nintendo Switch analogy is coming up a lot it’s sad I didn’t think of it while writing the article 😅
The headless architecture is usually created with abstraction and extendability in mind. This means that not only can it be presented by different types of clients (websites, mobile apps, etc…), but it also allows you to easily integrate your server with other services.
With traditional architectures everything is typically managed together on the same server as if it’s all a single module rather than separate modules. This means that when you need to integrate a new service or make changes to the server there are so many components that are dependent on one another that it can become a hassle or you’ll even need to do a lot of hacky solutions.
A headless architecture typically eliminates the need for hacky solutions because it’s designed to be a single component or module that can communicate with other components or modules, rather than having them all depend on one another.
Not sure if my answer is clear enough but I hope you found it helpful!
That's what I wanted to hear! Thank you! I keep on reading headless = "no front-end" and is not about that at all.
Also I think that is key that on a headless service, the service is a full product itself when on a client-server application both parts form a whole.
Thank you for your response.
The no frontend thing is just a part of it that explains the term “headless” but the entire architecture focuses on much more than that!
Thank you for your comments and for reading the article
It's not headless, it's just someone else's head.
Wait, what?
🤯
Thank you for the article. So client-server architecture is equal to headless architecture? Can we also called firebase as headless CMS?
Please refer to this comment:
dev.to/shahednasser/comment/1nbkj