With another successful DrupalCon behind us, we’ve had time to reflect and rewatch all of our favorite sessions. A couple of buzzwords, in particular, stood out to me the most: headless and decoupled. Not only were there multiple sessions about the two topics, but I also heard those buzzwords coming from many attendees on the exhibit floor. Although I’d heard about “decoupled” and “headless” before the Con, I realized I didn’t really know what either one meant. Even as a non-coder it’s important to be in the loop about the latest trends in programming.
Before we delve into decoupled versus headless, it’s important to note that a traditional CMS is also known as “coupled” CMS. With this infrastructure, the front end and back end have a tight connection. Content is created and managed on the back end. Content on the back end identically corresponds with the front end.
Decoupled CMS
A decoupled CMS takes the traditional CMS and splits the back end and front end into two different workflows. One system is dedicated solely to content creation and storage, while the other system is used for data and front end output. Using APIs, this system can deliver content to any design on any device, making it very flexible and efficient.
Headless CMS
A headless infrastructure is closely related to the idea of a “decoupled” CMS. Both are similar in that they manage content on the backend and use APIs to deliver that content to the front end. The main difference between the two is the fact that a headless CMS doesn’t have a defined front-end, hence “headless.” Instead, the content lives on the back end indefinitely, until a RESTful API delivers it to an application on a device.
Much like a traditional CMS, a headless CMS still includes a database for content to read and write to and an administrator interface. The only difference is there’s no front end to combine the database data with HTML. Instead, a developer (like one from Sevaa Group 😉 ) will need to build a website and use the Content Delivery API of the headless CMS to deliver the content to front end users.
When is a Headless CMS Appropriate?
With a headless CMS, developers aren’t restricted to a particular technology; they can use any technology they’re comfortable with to build a back end for content storage. This is also a great method if you’re developing an application using Javascript or static site generators like Jekyll or Middleman. In addition, headless CMSs come in handy when building any sort of native mobile application.
Finally, this strategy is commonly found on e-commerce sites. In fact, in our review of DrupalCon Seattle, “Delivering Headless Commerce” was among our favorite sessions. Senior Drupal Consultant at Commerce Guys Matt Glaman described headless commerce as a division between the customer experience from the core business application. In their research to deliver headless Drupal Commerce, Commerce Guys built the Commerce Cart API to provide decoupled “Add to Cart” forms and shopping cart interfaces.
Why Should You Care?
Not only is the headless approach becoming more popular, but it’s also a lot more efficient for developers. Despite what kind of front end is already in place, a headless CMS allows developers to worry strictly about the backend. When content is ready to be delivered to the front end (whether it be Drupal, WordPress or a custom built website), an API simply calls on the content and sends it to the appropriate application or device.
Finally, a decoupled or headless CMS allows developers to choose a technology he/she is familiar with to build a backend, as opposed to be limited to a specific stack for a specific CMS. This means the developer won’t have to troubleshoot issues with an existing stack of technology, and it’ll be much easier to optimize pages for SEO. Regardless, you’ll need a “front end” to send your content to. Talk to Sevaa Group about building your next website using a “headless” CMS.
