Headless Drupal: Driving User-Experience on the Mobile Web
Drupal’s power lies in its flexibility, and the fact that developers can create complex content models.
An admin interface helps developers manipulate the backend content repository, to reflect changes in the front-end framework, and vice-versa. This tight coupling between the frontend and backend have been used to develop some of the best websites, e-commerce applications and web-apps. Over the years, Drupal has emerged as a very powerful framework.
However, this approach was more relevant a decade ago when mobile applications were still in their infancy, and when enterprise applications worked in silos without too much interaction between them. But a lot has changed since then. Today, the mobile web is changing the way business is done.
Simply replicating a part of the desktop application on a mobile app is not only costly, but also robs the app of its power. A more efficient and cost-effective approach is to have the backend content repository deliver content to a variety of powerful applications working on various devices. This means, a single backend Drupal CMS should be able to push content to a mobile app, and any other enterprise application at the same time. Using Drupal in this way is what we call “Headless Drupal”.
The necessity of such ‘cross-platform publishing’ is what is driving the popularity of Headless Drupal or decoupling of the backend CMS from the front-end framework. But this is not the only reason Headless Drupal is relevant but equally important is the fact that creating unique user-experience is differentiation strategy for business organizations.
A whole new set of front-end technologies have emerged using which we can create faster, responsive and interactive apps that offer a rich experience to the end-user. Front-end developers need not know the intricacies of backend drupal programming and still they can harness the power of Drupal’s powerful content-modeling capabilities, and its equally effective editing interface.
So how is Headless Drupal different from regular coupled CMS systems?
A traditional CMS has three components to it:
- The database which stores and maintains the content
- An admin interface that editors can be use to manage the content models in the database
- The templating layer: basically front-end that is use to implement unique look and feel for the website
In a Headless Drupal website or web-app, the content for the site/app is accessed using an API through formats such as JSON or REST. And front end specific application framework like Angular, Backbone, Ember or Knockout delivers the API output onto the front-end template layer. We do not use default Drupal templating layer to display the data or content.
So when should we go for Headless Drupal?
- If you are building your website where content can be consumed by different applications and repurposed based on context. Headless Drupal will allows you to have different architecture for editorial system and the publishing system. You can event have one common editorial system for multiple publishing system.
- You want to rely more on front-end architecture for scalability. And it makes more sense as having no heavy CMS in the delivery architecture means less of server processing. Static HTML files are easier to handle anyway from scaling perspective.
- You are building an application where managing content is just one part. CMS is secondary function of the larger application.
- Or sometimes you want to create two different application where one is used to create content like we do in staging environment. And after final approval, content is published to another publishing system. You do not require front-end for staging environment where content is created and reviewed only.
Headless Drupal is not without its share of adversaries or criticism. However in certain scenarios, its benefits far outweigh its drawbacks. In a world where user experience is critical for long-term success, decoupling CMS and front-end, which is what Headless Drupal achieves, is no longer an option, but a necessity.