If you’ve reviewed the CAPABILITIES section of our company website, you know headless content management systems (CMS) are one of our specialties. In fact, our crew was quick to embrace this technology and the flexibility and scalability it affords both web developers and content creators. To spread the word, we published a series of Culture Foundry CULTIVATE blog posts in 2020 and 2021, discussing the

• Basics of headless systems;
• Optimal front-end options and the best back-end options for a headless system;
• Types of CMS software that work best in a headless implementation;
• Pros and cons of headless systems compared to traditional, “coupled” content management systems; and
• How to develop a blueprint for a headless CMS strategy.

While our enthusiasm for headless systems hasn’t dampened, we have learned some valuable lessons and shortcuts while building headless systems over the last couple of years that we wanted to share with anyone considering a headless implementation.

To capture those learnings, I spent time with Culture Foundry Principal Engineer Forrest Moulton, who was part of the Culture Foundry crew that earlier this year launched a headless system for NYRA Bets, one of the country’s largest online wagering platforms.

Here is a summary of what Forrest shared with me:

Lessons learned while implementing headless content management systems

JKL: Thanks for sharing your point of view with us, Forrest. For starters, can you describe the basics of how a headless content management system works, compared to how a monolithic (non-headless) system operates?

FM: A headless CMS is only that, the content management system. There is no publicly viewable visual presentation layer. All interaction is done behind a login and is only intended to be used by site administrators and content creators.

This content data is then served via an application programming interface (API) in a standard format. So, think about it as your content only being available through a simple text file. There are no browser interactions, styles, colors, rendered images, etc.

Then there is another application built purely for the purpose of visually rendering this data. That application handles all the fancy things, like structure, colors, styles, animations, and much more.

A monolithic (or “coupled”) system has all the parts as one application. So, instead of two applications you have just one. The same system that is used for backend administrators and public visitors is the same.

JKL: How does a headless implementation change or affect the relationship between the front and back ends of a website or web application?

FM: It’s probably more accurate to think of a headless system as a “decoupled” one. This explains how it functions much more clearly. The front end and back end in a decoupled setup are two independent applications that communicate through an API. This API can be read-only, meaning the front end can only view data or read and write, allowing the front-end application to modify data through the back end’s data store.

JKL: It sounds like using this configuration, you can pull a lot of different data sources into the same website page. Can you elaborate on that and provide any examples of projects you’ve worked on that illustrate this?

FM: An application can pull data from a multitude of sources. A CMS reads and writes data to a database, and a front-end application can consume data from multiple sources. This includes, but is not limited to, APIs, data stores, etc. Although the application can make as many requests as necessary to retrieve data, this can have an impact on performance.

When making requests to more than three (3) data sources, it is best to implement a query language, something like GraphQL or MuleSoft. Both of these types of “middleware” can combine data together from multiple sources and only require the requesting application to make a single request. This greatly enhances performance.

Recently, we were able to implement a new marketing website for NYRA Bets, the official online wagering platform for the New York Racing Association and its family of horse racing tracks. The NYRA Bets team needed the ability to make requests from two data sources: a content API, and a wagering API. By using a stand-alone application, we were able to build a custom interface that served both public content and user-specific (logged-in betting customer) content.

We were also able to make requests from both datasets, based on data retrieved from each one of them. For example, we can show different racetracks to site users based on where those users are located, which is important because the ability to legally wager online depends on the U.S. state, or country in which you live.

JKL: In terms of general features and functionality, what additional flexibility does a headless system offer to site developers and content managers?

FM: Here is the short list:

1. Enables omnichannel content strategies: Being able to create content that can be pushed to multiple channels and to be repurposed among channels.
   
2. Increases site speed and performance: This results in better search engine optimization (SEO), as the Google search engine now weights site performance heavily in its organic ranking algorithm.
   
3. Reduces security exposure: No need to elaborate on the benefits of better site and data security.
   
4. Connects site content to an infinite array of outside services and software:  Site content is no longer siloed from adjacent systems like customer relationship management platforms (CRM), artificial intelligence and machine learning software, site personalization tools, or localization platforms.
   
5. Flexible CMS selection or multiple CMSs to power content: You pick your technology stack; you aren’t married to one software solution.
   
6. Simpler to scale at architecture level: Scale up or down based on your business needs without a lot of hassle.

JKL: How does a headless implementation compare to a coupled CMS in terms of the amount of time and cost it typically takes to build it?

FM: A headless CMS is going to always be more expensive and time consuming upfront. Even though there are a plethora of open source and SaaS based CMSs available that provide a lot of features out of the box, going headless means that the entire front end (public facing) part of the site will need to be designed and developed from scratch, and this makes initial implementation more costly.

That said, this makes your front-end application much more versatile and “future proof.” Let’s say you want to bring in more data from outside sources (CRM, social media, personalization, tracking, etc.) These additional sources can more readily be added through a stand-alone front end, as developers will not be restrained by the CMS’s framework to implement these additions.

Several coupled CMSs do offer plugins to accommodate some of these integrations; however, as you add more plugins and add ons, you make the system much more fragile, and that can also complicate site speed.

As you start to expand your server resource, consumption grows. And then you have to expand your infrastructure to support these demands. You could be looking at custom hosting and/or expensive upgrades to cloud-based hosting, so the additional real and opportunity costs add up.

Coupled CMSs are a great option for smaller businesses that need straight page content with light front-end functionality. This solution is cost-effective, and offers endless options for plugins to expand your CMS’s functionality, along with pre-designed themes that can give you a great start on your front-end build.

JKL: Understanding a headless CMS may be more expensive upfront, are there ways it could save you money as your website matures or as technical and/or aesthetic updates are needed?

FM: If you foresee your business needing omnicontent (content distribution across multiple channels), then a headless approach should be a very serious consideration for you. If you work in a B2C or retail business, you may eventually expand to a physical store and need to push content to in-store displays. Or you may need a cohesive inventory system, an in-store checkout system, a mobile application, etc. A headless option would allow you to have multiple applications that all can perform CRUD (Create, Read, Update and Delete) data from a single source of truth.

If you plan on bringing in several data sources, a stand alone front-end application would be a much more future proof solution. Let’s say you started with a retail store and wanted to expand to e-commerce, but you already had a retail system for inventory, accounting, and other business operations. Today, the majority of these systems allow credentialed outside access via an API. Now, your online storefront and physical storefront can both pull the same inventory data and add sales entries and product returns to your accounting system. This is just one example where this flexibility of a headless CMS would allow you to future proof your customer experiences while making your marketing-communications and record keeping easier to manage.

JKL: Can any web developer build a headless CMS? Or does it take special knowledge and skills? And if so, how can that affect the cost?

FM: Depending on the choice of technology, the CMS implementation could be pretty straight forward, allowing any developer the ability to work on it.

If the business needs are more complex, then a more seasoned developer with specific framework knowledge would be needed to modify the CMS to produce the proper data structure and allow for easy API intake by the front-end application.

These days, most front-end developers work in the common languages used for the front-end application, such as Node, React, and JavaScript. In either choice, the system requirements would heavily determine the cost and type of developers needed to complete the project.

JKL: When it comes to content creation and editing for non-tech users, is it harder to work within a headless CMS (e.g., if you don’t know how to code)?

FM: There are two parts to this question: The first is that in my experience, it’s  actually easier for a non-tech user to do his/her/their work in a headless CMS. The content creator does not have to worry about the final visual display of their content. They just have to worry about the content and content type they want on the page, and then determine the structure of that content. From there, the front-end application handles the visual rendering per a pre-set styling library.

The answer to the second question is “yes, it can be more difficult,” as some monolithic CMS editor interfaces let you add custom HTML and CSS to the page, and will render it no problem. Also, an administrator can easily add some plugins to expand functionality. To allow these changes to render on the decoupled front end would require a developer. However, adding inline styles, HTML, and lots of plugins can lead to collisions with other parts of the website and hinder the site’s performance when pages render.

JKL: From what you’ve learned in the last few years, what types of companies and organizations would benefit from a headless CMS? What types of business models make the most sense for this solution?

FM: Right now, I think the following business types would benefit from a headless implementation if they can afford the upfront investment of time and capital:

1. Larger-scale businesses that already have–or will have–a multitude of integrations will benefit  long term from this type of architecture.
   
2. Any business that has an ever-evolving brand could easily update the look and feel of its website and applications relatively quickly and cost efficiently.
   
3. Businesses with multiple revenue streams–such as in-person retail, e-commerce, and sub brands–that want easier ways to track and manage inventory and evaluate sales results.
   
4. Any business where constant site uptime is critical and affects revenue.
   
5. Any business that has omni-channel needs for marketing across a multitude of technologies, including those that use both websites and mobile apps to engage customers and sell products and services.

JKL: In contrast to the previous question, in what situations / business environments would a headless CMS not be a good solution?

FM: A smaller business with a smaller team and operating budget would be better off with a coupled CMS that renders all parts of its website with one technology and one application. This type of CMS can be built faster and with less upfront investment. Bottom line, any business that only needs a web presence for marketing purposes should consider a coupled CMS.

JKL: In your role, what have you learned about headless CMS builds that you didn’t know when you started working with them? Any “personal hacks” or shortcuts you’ve discovered? Or mistakes you’ve learned to avoid?

FM: Here are some of the most important things I’ve learned:

1. Always create a full requirement of what the content team will need the ability to do–and what they may want the ability to do in the future without having a developer on staff.
   
2. Always look for open-source libraries that can cut down on development time. For instance, WPEngine is now supporting headless WordPress CMSs, and has an open-source front end called FaustJS. Using a shortcut like this reduces development time and cost.
   
3. Create good data structure, so the requests coming into the front end are as clean and simple as you need for the specific renderings.

JKL: What is the most challenging thing you’ve encountered when building or working with a headless CMS?

FM: The two things that have been a struggle in this architecture are localization and preview capabilities. If these are important to the end project, they should be well thought out ahead of time and planned for.

Since we’ve built a system that required both, we’ve made a lot of headway on accomplishing this. For instance, WPEngine’s FaustJS has a preview with WordPress built into its base framework. Also, systems like NextJS latest builds have localization built in, where you can set a different endpoint for grabbing language versions of the content from the CMS API.

As time goes on, I believe more technology frameworks will have these more complicated features built in, which will cut down on time and development costs.

JKL: What types of software and digital tools do you recommend using while building a headless CMS? What are your go-to products?

FM: Here is a shortlist of the products we use regularly:

1. We always build our front end from NextJS, which we have done for several years now–and that looks like a strong choice from the community now as well.
   WPEngine’s FaustJS is built on top of NextJS as well.
   
2. If you are developing a data-heavy website (tables, sorting, filtering, etc.), Ant Design has great components that have a fair amount of this type of functionality built in.
   
3. The CMS is pretty open to what the editors want to have control over. That is mostly determined by the needs of the client. WordPress has a best-in-class content editor, but can be trickier to implement on the front end via the API, and it also requires constant updating for security reasons. Something like Django (Python) is great for security and API generation, but lacks the type of content creator interface offered by Gutenberg in WordPress. So. CMS selection is very flexible, depending on users’ needs, and that is why you really need to scope out the current requirements and future requirements as the first part of the project, so that the CMS selection can grow with the business.

JKL: As you’ve had more experience in this space, has your opinion changed at all about the attractiveness of headless CMS solutions?

FM: Yes, but I have been exploring blended options with a heavy use of something like GraphQL. For instance, why not build multiple, “micro CMSs” from one base framework that then is molded specifically for the specific content editors’ roles and needs? Then we could use that base framework to render certain items, such as basic web pages, through its templating system.

For more complex front-end requirements, we could build a series of micro applications that can be embedded into the page. These applications could do the majority of their work client-side, and take pressure off of server resources.

I think we have to start to understand this–and user needs–and offer a blended option to provide the best of both worlds to our clients.

JKL: Looking down the road, where do you see headless CMS technology heading? Do you believe it will become more commonplace, lose popularity, or will it evolve in new directions?

FM: I think we will end up in a blended mode. This means there will be parts of the front-end application rendered with the CMS framework’s native language, and other parts that are stand-alone micro applications that do some of the more heavy interactive lifting.

For example, we do a lot of projects for clients in the horse-racing industry. The most interactive part of that development work involves pulling real-time racing and wagering data data and updating the page where that data is integrated and displayed on the fly, without the need for a page refresh by the site visitor.

Horse racing/wagering sites and applications also require video streaming, race results, and wagering payouts, which are coming in real time. This would be nearly impossible to accomplish with a fully coupled CMS solution, and making it happen requires the use of heavy client-based interactions and data from multiple data sets.

In the future, I can see this becoming a micro application that is embedded.  Keeping this as a micro application allows for faster iterations, bug fixing, and development, without having to worry about all other parts of the site.

I also believe that this allows more developers the ability to work on sections of the web application without needing to know it as a whole. This would reduce the wait time for app releases and new developer onboarding. This means more time and cost spent on the development and less time and money spent on onboarding.

Is a headless CMS right for you? We’d love to help you find out!

Complete the form below and we’ll be in touch ASAP: