Headless Drupal - Overview and resources

Headless Drupal is already a thing and people have started using it for building websites. Lets see what is headless drupal and why it is required.  Headless drupal concept will mainly be of help to theme developers (front-end). Today we can create great themes using HTML, CSS, Javascript. however when we try to integrate with drupal framework, we have to spend days to make things working. While Twig framework being added to Drupal 8 is a big plus point, there, front end developers still want to craft things using css, html, js. 

AngularJS or Backbone is capable of briding the gap however there has to be a structured effort for this. Fortunately there is a group of people who are already working on this , idea is to use Drupal as a backend content repository and REST server. A REST server will make it possible for other applications to read and edit the data. Typically Drupal is used to store and manage content and it then provides that data to your app built with Angular, Backbone, Ember etc..  

 

Manifesto

  • Drupal as preferred back-end content management system for designers and front-end developers.
  • Drupal's main strengths lie in the power and flexibility of its back-end; its primary value to users is its ability to architect and display complex content models.
  • Client-side front-end frameworks are the future of the web.
  • Drupal must be services oriented first, not HTML oriented first, or risk becoming irrelevant.

How to get there ?

  1. Simplify working with Data Models - The way data gets sent and used by the presentation layer needs to be changed. Today data is conflated data and our controllers make it messy for front-end developers to reliably get the output they'd like without at least intermediate PHP skills and a full PHP debugger. Front-end communities only are required to have skills in HTML, CSS, JavaScript, and being able to read REST API documentation. In order to both attract new front-end developers to Drupal and enable Drupal to power the webapps of the future, we need to both simplify and ease working with our data models, aligning the interaction model for each.
  2. Unmushed Controllers - Without a proper separation of concerns drupal front end becomes hard to debug as controller behaviour needs to be understood. To get to headless state, block/views will be a singl place to store all interactions between a model and a view. Later larger blocks can be made up of smaller blocks. This will do away with need of having view modes for entities and blocks solely as content. Today anything that gets rendered  to a page is required to have a controller that is separate from the data model. Controller determines -  what data is available, and what view is being used. Since its controller it does not hold or manipulate any content, but only to determine what content is available to the view of the content, and how to update the model's state (i.e. form entry, AJAX requests, etc…). When we implement this it would be more of Views being used to generate different data streams and block would be created eparately to display that data stream.
  3. The Views, the Assets, and the Princess  Drupal has assets tied to views and doing away with alters (especially for views and assets) is that the system can know what assets, and what each asset depends on, are required for a page to load before it loads. This will allow for smarter asset bundles and better headed Drupal performance. If coupled with a page management tool (page management tool for managing what goes on a page, not layout management tool for managing how content gets laid out on a page), headed Drupal performance could greatly improve through technologies like ESI and standard, easy to work with content lazyloading. It would also benefit headless Drupal by providing a single API endpoint for all content at a route, allowing a single HTTP request instead of multiple, small HTTP requests to build a page, giving site builders a simple, easy, and standard way of controlling content on either a headed or headless Drupal instance.

Source - https://github.com/davidhwang/horseman/blob/master/dogfooding.md 

For those looking to develop Headless Drupal websites, there is no need to wait for Drupal 8. You can start with Drupal 7 also. You will need services modules and restws module . Drupal 8 opens up doors for headless drupal as Core includes both a REST interface module and a brand new routing system built on the Symphony2 HTTP kernel. This provides a lot of opportunity for headless implementations both for beginning and more advanced developers. Check this post https://drupalize.me/blog/201402/your-first-restful-view-drupal-8 

Sites already using Headless Drupal methods

Resources