Nowadays, it seems impossible to code without using some new, bright, and shiny JavaScript framework, but at the same time the end user wants to be able to modify content themselves. For this reason, the headless CMS concept was born: the aim was to detach the (sometimes more, sometimes less) user-friendly Content Management System (a.k.a. where you put the content) from the front-end (a.k.a. how you see it).
Many headless CMSs began to emerge, but as always, everything comes with a cost: and for some headless CMSs, this cost was really high.
So we found a way to cut the costs and still enjoy the benefits of a headless CMS: using WordPress as a headless CMS, even though it was not designed to do so.
But was it worth it? Let’s find out!
What is headless WordPress
We already know what a headless CMS is (as mentioned before, it means that the back-end editing tools are separated from the front-end stack to display the content), and we surely already know WordPress (the open-source CMS that dominates the market, powering almost 43.5% of the entire Internet).
What some may not know is that WordPress natively offers a REST API that allows fetching data in JSON format.
In addition to this, the community also introduced GraphQL by creating WPGraphQL, which provides a more flexible type of API.
So, WordPress can actually be used as a headless CMS without any additional cost.
The benefits of headless
In general, a headless CMS has a lot of advantages; I’m not saying otherwise. But I think they are worth only if your team can afford it. I mean: with great power comes great responsibility. And headless CMSs are really powerful.
Flexibility
One of the primary benefits of a headless CMS is the flexibility it offers. By decoupling the backend from the frontend, developers are free to use any technology stack for the frontend layer. This means that we can use modern JavaScript frameworks like Vue, React or - in our case - Next.js to build a dynamic and complex user interface. The separation also allows for the ability to redesign or update the frontend without affecting the backend content management system. Moreover, collaboratively building your frontend is sometimes a lot easier with Next than with PHP (I’m not one of those that spits on PHP, but it’s a fact that nowadays a lot of devs don’t learn it anymore).
Multi-channel support
We live in an era where content is delivered to users across various devices, platforms (websites, mobile apps, smart devices), and sometimes you need to deliver the same content to different channels. A headless CMS allows you to simplify this process and the content management, because it delivers data through APIs that can be used from any channel.
Specialization
Another benefit is that a headless architecture allows teams to focus on their areas of expertise: frontend developers can build a tailored frontend experience using all the best and shiniest tools they normally use, while back-end devs concentrate on tweaking the backend and the CMS to deliver the data they need, and content creators can only focus on actually creating the content in the CMS without worrying about how to display it.
The drawbacks of headless WordPress
WordPress seems to be a good and affordable choice for those who need to build a product with a headless CMS and don’t want to spend a lot of money to do that. However, we found out that the drawbacks were - at least in our use cases - more significant than the advantages.
Maintenance cost
Operating a headless WordPress setup can introduce additional maintenance overhead. Since the frontend and backend are separate entities, they each require separate updates, security checks, and performance optimizations. This dual maintenance can increase the time and resources needed to keep the system running smoothly, and in small teams like ours, it can be significantly time-consuming. Plus, if you don’t update one or the other, you will end up with a broken system.
Plugin support
One of the main advantages of WordPress is the extensive plugin ecosystem. However, in a headless configuration, many plugins may not function as intended or may not work at all without implementing a custom solution to pass their data to the frontend. And sometimes even those plugins with unofficial or official support for headless CMS (like those that have integrations with WPGraphQL) still don’t work as well as they should. We found headless WordPress to be still immature from this point of view.
Draft and WYSIWYG support
WordPress has a very good support for WYSIWYG (What You See Is What You Get) editors. But in a headless configuration, it’s not possible to use them (or at least, you should implement a custom system to do that), so the editing experience may be less intuitive (if WordPress is not properly configured with helpful custom fields or other things to help with that). Also, implementing drafts becomes a bit more complicated, as you need to ensure that the user is logged in and can edit the content, so you need to invoke APIs with the right permissions and tokens. Not something as simple as setting “draft” in the traditional WordPress editor.
Server resources
Typically, any inexpensive shared hosting supports PHP and MySQL, thus also supports WordPress natively. However, a headless configuration is often done using JavaScript frameworks that often need to use a Node.js server, which is not always available. So for low-budget projects this can be a problem, as you need to purchase hosting with the proper resources. Also, often you need to host your WordPress installation separately from your frontend, so the server complexity becomes higher. Not all the clients are happy with that, so traditional WordPress is often a better choice.
Debugging
When choosing a headless WordPress configuration, you have two different entrypoints that need to be checked for possible bugs. You need to ensure that the WordPress side has no errors, and that the APIs are working as expected, returning properly formatted data (or meaningful errors), and you need to handle those properly in the frontend. Double the complexity, double the cost of debugging, double the headaches.
Conclusion
I’m not saying that WordPress cannot be used as a headless CMS. Actually, I think that it remains a great choice if you need headless architecture and you don’t want to spend a lot of money.
The real problem is: when do you need headless architecture? It does not matter if we choose WordPress, StoryBlok, Strapi, or other CMSs. The problem is at the core.
As developers, we often try to use the most modern, most advanced technologies, because we feel that if we don’t, we are not good enough, not senior enough. However, we should start from the objectives and try to understand if headless is really the best choice. More often than not, it isn’t. We have to admit it sometimes and save ourselves a lot of headaches.
And maybe we can become better developers by choosing the right technology for the right project. There will always be time to learn new things when they are needed.