A couple of weeks ago, I was able to jet down to Los Angeles with a few of my esteemed colleagues to soak up some sun, and more importantly, some beautiful Drupal knowledge. We went down with empty brains and high spirits, excited to take in everything Drupal that we could. One of the big topics this year was the concept of a ‘headless’ CMS, more specifically and obviously in this case, “Headless Drupal*”.
* Note: this idea of a headless system can apply to any CMS with the capability of making content accessible through a web-services API. I’ll be talking specifically about Drupal in this case.
So What Is It?
Drupal is a highly functional, customizable, modular, and community-driven CMS. It’s safe, secure, and has the ability to manage large volumes of content. Its powerful backend has helped businesses create scalable and flexible websites that can serve static and dynamic content whenever needed.
The problem, however, is that sometimes Drupal’s theming layer isn’t exactly a great experience to work with. Creating intricate and interesting front-end layouts usually requires the addition of more and more modules (Panels and Panelizer, for example), or a lot of back-end PHP logic. What if we could output the data in a different way? What if we could keep the strong Drupal back-end and ditch the theming pains? This is what Headless Drupal attempts to do.
Why Go Headless?
So, what would that actually do for us web developers? Why do it at all? Well, it turns out that we can get quite a few benefits by implementing this. By separating the front and back-end systems, we can let our front-end and back-end specialists focus on what they love. The front-end gurus no longer have to be constrained by the Drupal theming layer. They can use all the tools and front-end magic that they want to render a beautiful and interactive site, while the back-end wizards focus on creating and polishing a streamlined back-end system.
We also get a lot of performance gains with a headless solution. By shifting the rendering logic to the client side, we can free up the back-end from having to create complex layouts based on its own PHP logic. The data is sent to whichever templating engine that you choose, and pages are built specifically for that data right in the browser.
There is also the benefit of the back-end being upgradeable at anytime. As long as your API isn’t changing, the front-end wouldn’t be affected by any changes in the back-end (for example, you don’t have all the module dependency that you would have on a non-headless site).
Some Issues Remain
Page caching also becomes much more difficult in a headless situation as well. When the pages are built on the server, they can be easily cached before they are sent to the browser. In a headless case, the pages are being built on the client side, so you would have to send the built page back to the server to be cached. Therefore you could end up with a lot of round trips to the server, which could result in negating any speed improvements.
There are also some question marks that still exist with server-side validation as well. How would you handle form input? User authentication? These are issues that are being tackled, but a well-baked solution currently does not exist.
If leveraged properly, headless web development has the ability to power incredibly fast, creative, and rich web experiences, but only in the right situations. Consider what the requirements are for your next project, and maybe a headless system is exactly what you need!
If you’d like to learn more about headless Drupal, check out some of these resources:
And for some examples of current headless Drupal sites:
The Tonight Show starring Jimmy Fallon(Node.js + Backbone.js