Rethink Your CMS Strategy

By

We work with many different content management systems for various clients. They all cover the basics, and each provides a set of unique features that clients value over those provided by the others. One of the major features a web content management system provides is the ability to manage content. This includes the ability to authenticate users, a rich content editing experience, media management, and more. So starting a new website on a CMS platform gives you a jump start, and saves money.

But if you're a developer there are unavoidable compromises. One of the biggest is that even if you love the back office features, you may not like the way it handles publishing. WordPress provides a good example. The back office tools are really mature, and so long as you manage the number and quality of plugins, it's pretty easy to navigate. But creating a responsive theme for WordPress can be tricky. You need to learn the WordPress theme architecture, the API (which is based on PHP), and maintain your changes to the theme across WordPress updates, among other considerations. You have to go "all in". But if you do there are some drawbacks, including:

  • following a CMS-specific publishing architecture,
  • learning a CMS-specific API,
  • learning to build CMS-specific plugins,
  • sticking to a CMS-specific development language,
  • accepting the risk of being left behind as new design patterns and web application paradigms evolve (like single page apps),
  • and maintaining compatibility across CMS platform updates.

Each CMS has its own way of doing things, mitigating some of the problems I've listed. For example, one of our favorite content management systems, Umbraco, has a pretty open ASP.NET MVC environment, allowing seasoned .NET developers an easy way to create templates. But it still requires ASP.NET and using their custom objects and methods to render content.

Off With Their Heads!

One of the ways a developer can address the limitations of adopting a CMS platform is to only use them for the purpose in which they excel: managing content. A developer can accomplish this with a headless CMS strategy. No guillotine required.

Marie Antoinette LET THEM SERVE CONTENT!
— Marie Antoinette (OK, not really)

The key to this strategy is being able to communicate with the CMS using a REST API, allowing a developer to create the front end of the site using any technology stack they choose.

REST stands for Representational State Transfer. It's a methodology designed to let websites, software, and services talk to each other in as simple a way as possible.

It's an inherently flexible format but implementations are expected to share certain core characteristics. Here are four key expectations:

  • Use HTTP methods explicitly: It takes place over the web with standard HTTP methods such as PUT, GET, POST and DELETE.
  • Be stateless: The client will include any state information needed in the request to the server and vice versa.
  • Expose directory structure-like URIs: Use familiar URL structures like http(s)://api.com/students/jane
  • Transfer XML, Javascript Object Notation (JSON), or both: There is a set of options for data exchange which REST implementations agree to use.

When executed properly, the website front-end should be able to run on nothing more than HTML5, CSS and JavaScript. This can be done with CMS platforms like the WordPress REST API, the Drupal 8 REST API, and SharePoint 2013 RESTful Services.

Another benefit of a headless solution is that you'll be able to provide managed site content and other data to dedicated mobile, tablet, and desktop applications.

Knowing all this, how would a headless strategy specifically address the limitations I mentioned previously? Let's take a look.

...following a CMS-specific publishing architecture

In a headless CMS implementation, the front-end is decoupled from the back office tools, allowing a developer to write it with whatever stack or pattern they choose.

...learning a CMS-specific API

This is a bit more of a dubious improvement, as a custom object and method API is replaced with a REST API. But generally speaking, a REST API is easier to use and is available outside the CMS environment, which is a huge benefit.

...learning to build CMS-specific plugins

Building the website with your own stack and pattern allows you to author components as you see fit, using most any technology you choose.

...sticking to a CMS-specific development language

Since the developer is building the website with most any technology they like the scripting language is part of that decision.

...accepting the risk of being left behind as new design patterns and web application paradigms evolve (like single page apps)

Since the developer is building the website with their own technology stack and development pattern, they can look ahead and future proof as needed. But even when they have to rewrite the website using completely different technologies, they can.

...and maintaining compatibility across CMS platform updates

The great thing about a REST API is that it's generally pretty static, other than additions. So as new REST API features are added, a developer simply leverages them in the website as-needed. The existing stuff keeps on humming along.

Sound Interesting?

If you have a website, intranet, or product that could benefit from a new architecture, we'd love to hear from you! Maybe a headless CMS is just what you need.

Michael directs all design initiatives, heads marketing, and builds cool software for Fynydd. He's also a husband, father, avid reader, advocate for reason and science, and autodidact.

Fynydd is a software design and development company that creates awesome user experiences for all kinds of devices. Our expertise has helped people to do things like:

  • Create a new product or service.
  • Automate processes and workflows.
  • Bring a mobile strategy to life.
  • Better interact with their customers.

How can we help you? Contact us and let us know.