Headless Drupal - Overview and resources
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..
- 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 ?
- 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.
- 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.
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