Do I need a headless Drupal website?

We get this question a lot. Should we build our website headless? It's not a bad idea. In fact, the premise sounds fantastic: the visitor loads a website only once in the browser and from then on he can enjoy a tremendously smooth user experience. This is certainly possible, by linking Drupal to a frontend application built in Angular.js or React.js for example. After all, Drupal is built to be API-first. 

But is it a good idea to build your Drupal website as a headless CMS?

The answer is, as often, nuanced and strongly depends on what you want to achieve. You have to weigh the advantages and disadvantages against each other. Let's first have a look at what a headless CMS is, and what these advantages and disadvantages are. 

In a series of articles on this subject, Dries Buytaert, creator of Drupal CMS and founder of Acquia, gives his vision on the future of this smooth user experience. He poses the question of how we can optimally approach this as an open source community, and what choices we need to make in doing so.

Today we know that Headless Drupal is a good application for these reasons:

• In a multi-channel approach, Drupal 8 fits in perfectly as a CMS that manages content centrally and makes this content available to apps, websites and other applications via Rest API.
• In some cases it is desirable to apply a headless setup: frontends that collect data from different sources benefit from this, as well as applications where speed and User Experience are fine-tuned down to the smallest detail.

The main advantage is freedom of choice. By linking the "back end" of the "front end", you can use Drupal as a CMS, and any other application as a visualization layer. The strong emergence of high performance Javascript frameworks over the last decade has opened the door for extremely fast, user-friendly frontend applications. 

The characteristics of such applications are often that, once the page is loaded, no new page loads are needed. The web app behaves like a mobile application: fast, smooth and user-friendly. This is also logical, because this frontend user experience is custom made. 

With this solution Drupal will still take care of generating the web pages, but in your project, you can still choose to provide part of a web page with a dynamic javascript solution. This combines the best of both options: Drupal still takes care of generating the HTML page, so all the advantages of your CMS are retained. Specific parts of your page will, once loaded, become a dynamic widget area, providing the smooth user experience we strive for.

Good examples of such use cases are displaying complex data such as weather maps, sports results, and other very specific "widgets". Providing a complex search experience can also benefit from this.

That's the question within the question. This has to be evaluatied on a project-by-project basis. Is it worth including the technical complexity of a separate javascript framework in my project to develop some dynamic features? Sometimes it may be better not to do that, and to limit yourself to a smaller javascript solution. Achieving the same result for lower development and support costs.

That's the question within the question. This has to be evaluatied on a project-by-project basis. Is it worth including the technical complexity of a separate javascript framework in my project to develop some dynamic features? Sometimes it may be better not to do that, and to limit yourself to a smaller javascript solution. Achieving the same result for lower development and support costs.