What is a headless CMS?

We talk a lot about headless architecture here. It’s something that I first discovered about three years ago when looking for a more flexible solution to more traditional CMS solutions like Wordpress and Drupal. Customers were beginning to demand sites that were better, more interactive, and behaved more like what they saw in native applications. I often found myself spending more time trying to make client requests and designs fit into the platform than building the features themselves. There were also great technical improvements coming to the world of web development from cloud deployed backends to radically fast and interactive javascript frameworks. The traditional CMS was struggling to keep up with the rapid pace of change, and we wanted to offer our clients the best in class. The traditional monolithic CMS model that I grew up with was crumbling.

A headless CMS (content management system), at it's simplest, is a CMS that only concerns itself with content management. Where monolithic CMS's (Wordpress, Drupal, Joomla & Shopify) allow you to both manage content and design a website, a headless CMS is just a home for your content. That content can then be access via API (application programming interface) to be delivered to any website, mobile app, internet of things application, etc. Clients can still update their data, without the fear that something they do will break the designs, and with a far more searchable and easier to navigate interface.

On the development side, even our smallest clients get a version controlled code base, a deployment pipeline, a node server environment, and a template and CMS that is customized to their business. No more FTP'ing files and just pushing things live, no more bugs with templates and plugins that didn’t quite work right. Most importantly no more frustrated emails from clients trying to figure out how to update that image in that slideshow plugin on the services page. With version control, testing, a lightning fast server, and a professional deployment pipeline, multiple developers can work on the same features without overwriting each other, properly test their work, and stage changes easily for clients to review before pushing them live. For that matter we could have as many staging environments as we needed all without duplicating any code bases.

From the client perspective Contentful can be configured to match the lingo of their business. I could set it up with models that reflected the naming conventions of their business as well as add helper text to every field so it was abundantly clear what would be updated. If clients ever couldn’t find where a piece of text was in the CMS, the solve was easy, just copy and paste it in the search bar and Contentful will tell you exactly where that line of text is. Clients were less frustrated now that they didn’t have to worry about breaking a template or clicking through ambiguous menus to find something.

Performance is the next reason for this change. Fact is a monolithic CMS is not going to be able to compete with a lightweight website that is configured just for what the site's purpose is. Wordpress is a Swiss Army Knife solution, it does a lot of things well, but when it comes to code performance your site should only have what is needed and discard the rest. Our motto here is a site is complete not when there is nothing left to add, but when there is nothing left to remove. We pride ourselves on the performance of our sites and it was something that despite my best efforts I could never get to the levels I wanted to with a monolithic system.

Our motto here is a site is complete not when there is nothing left to add, but when there is nothing left to remove.

Contentful also has a robust image CDN that allowed for URL based transformation of images. Instead of using background images and creating multiple asset sizes, you can specify a width, height and cropping behavior, and get back exactly what the template called for. They even have an option to center people’s faces so now clients can upload whatever aspect ratio they want and the template handles the rest. This type of functionality was something only my enterprise clients had when using tools like Scene7. Now this is democratically available to all. This makes image implementations more accessible, performant, and easier to manage for all parties.

If you still aren’t sold on the headless model just take a look at what Drupal, Wordpress, and Shopify have been up to for the last few years. All of them have been building out API access to their content to allow users to free themselves from their monolithic architectures. In fact we love using the Shopify API for e-commerce, this way we get the best of both worlds, a world class e-commerce transaction platform, and a pro-grade site architecture and development pipeline with zero design restrictions. The future is headless and the benefits are far greater than simply allowing developers to use fancy new frameworks. Modern build pipelines, easy to manage staging and development environments, code safety, ease of use, and performance are just the beginning of what we can begin to offer everyone not just enterprise businesses.