Called decoupled or headless (hence the first image); Drupal has a technique that has gained solidity through the last years because of the advantages and rewards it provides against the traditional Drupal management. In this blogpost we will talk about what this technique is,its pros and cons, and how to us it.

Decoupled Drupal, what is it?

Decoupled Drupal is the process of using a different frontend rather than Drupal's default one. You can use frameworks like Angular, React or Ember to approach the frontend for your application or site. You still use Drupal's backend solidity to store manage data. The decoupled Drupal backend and the frontend communicate with each other via a RESTful API configured in the backend. This RESTful API functions by using HTTP requests and responses between server and client.

This is no new concept; there was already cases of impelenting deocupled Drupal in previous versions of the CMS like 6 and 7. Nimblersoft has implemented decoupled Drupal in Drupal 7 with an iOS app compiled in Phonegap and AngularJS. The app gets info from the server by requesting a json file. In our experience, Drupal is mainli used to drive native and single-page applications.

Before getting into explaining the RESTful APi and such, let's review a little history of the web.

Web 1.0

In web 1.0 we have a server hosting flat assets and a client who reads and shows these files directly. In this model we have a webmaster who manually writes and uploads markup to the server.

Web 2.0

Web 2.0 introduces early versions of CMS software, and the server side gains some strength by using database management solutions such as MySQL. The CMS is responsible of retreiving data from the server, rendering this data in a template engine and sends the rendered page to the client. Since web 1.0, the web models predicated the idea of a full-page refresh on each state change such as data submissions or requests between server and client. Let's review this behavior below:

In this example, a user wants to subscribe to a website's newsletter. The user submits his/her e-mail address in the form and presses 'Submit'. Afterwards the site does a full-page refresh to process this action and shows the response in a new rendered page. This is a logical behavior technically speaking, but does not provide a good user experience beacuse you sort of waste seconds on every page refresh.

To solve this issue, AJAX (Asynchronous Javascript And Xml) came to scene. AJAX is a dynamic way of server-client communication via requests and responses. 

With the implementation of AJAX requests and responses, applications became more dynamic and user-friendly because of the decreasing needs of a full-page refresh. Let's check the same newsletter example, but now, using AJAX:

In this case, when the user submits his/her address, the client sends an AJAX request to the server to store the address in the database. Afterwards the server sends a response notifying the client if the request was a success or failure. The client shows this process graphically in the way of a spinner and shows the notifications in the form. Simple behaviors such as this does not require a full-page refresh to function properly.

AJAX discards the need of a full-page refresh, but as more dynamic needs increased, an applications could have many AJAX communications going simultaneously. These communications could collide witch each other causing some serious bugs. Now, the main problem lied in the need of a control of these AJAX requests and responses.

Web 3.0

In Web 3.0, server-client communications are managed by a RESTful API. The RESTful API takes in HTTP requests and offers responses that are directly injected in the client. The client application has to be built in a framework that can handle these HTTP communications. The main HTTP requests are GET, POST, PATCH and DELETE.

GET requests the server to send specified information, POST requests the server to store data in the database, PATCH edits existing content in the server and DELETE erases data from the server. The server answers these requests with either data or a notification notifying the client if the request was succesful.

Rather than getting just data like in AJAX, the client receives a rendered portion of the page, or even the full page. WIth RESTful API, full-page refresh behaviors are no longer viable. By far we learned why decoupled Drupal is and how it works; now let's check its benefits, risks and the best cases to use decoupled Drupal.

Why Decoupled Drupal?

Content management systems have always been monolithic in the way that we have a single system being in charge of everything in the site or applicarion. Templating, renreding and presenting data is controled by a server-side language, in Drupal's case being PHP.

As shown in the chart above, the left side represents a monolithic Drupal structure, where all frontend and backend actions are managed by PHP. The left side shows the structure of a decoupled Drupal application, where Drupal only manages backend and API operations while another framework is used for the frontend. Being decoupled, Drupal can be the center piece of an app ecosystem, with a single backend and multiple frontend applications. Take for example the graphic below , where you have a single Drupal backend and applications running in iOS and Android. Both apps can communicate with the same server via HHTP requests.

By decoupling you gain the benefits of separation of concerns wich means front end and backend operations can take different approaches as long as the backend provides the API and the frontend uses it. Also, every data addition done in the server can be read and consumed by all user applications connected to the server. Decoupled Drupal can be vert useful when in the same project we have centered teams, like the pure Drupal backend team and the frontend team; and making these teams learn technologies and conventions are not viable. The application or site can be decoupled to prevent this issue and let the teams focus on their main field of action.

Decoupling Drupal also takes some risks with it. Decoupling adds an additional point of failure hosting and domain wise. If your frontend applications goes down, you don't have a way for the client to read and consume data from the server. Same way if the backend service goes down. the frontend application has nowhere to get the information from.

Also we are no longer using Drupal frontend features. As a themer and frontend manager , I love many of the modules the Drupal community has created to provide solutions for presenting data such as Panels and Display Suite, also the smooth user experience Drupal itself provides. By decoupling you lose all these benefits because, well, you are using a different frontend solution.

There are some cases where you should and should not decouple Drupal. It's a good idea to do so if you have a site powering multiple apps or sites, such as the example above with the iOS and Android apps. Decoupling is almost necessary if you have multiple centered development teams , giving the only rule to provide and consume data via a RESTful API. A Drupal powered content repository  should be decoupled for multiple applications can access data within this repository. Where you should NOT implement a decoupled Drupal service is in standalone applications or sites; it's just unnecessary and adds an additional point of failure just for the hell of it.

Setting up Drupal as a decoupled backend service

Some modules are needed if we want to set Drupal as a decoupled backend service. We will need HAL, HTTP Basic Authentication, REST UI, RESTful Web Services and Serialization. These modules build up Drupal as a RESTful API platform with basic authentication and user interfaces for its configuration. These modules can be installed using drush using the following commands, don't forget to refresh your caches after installing:

There is little configuration to be made in these modules, but if you want to change some settings in the REST module you can do it in

Admin > Configuration > Web Services > Rest.

In this page you can configure which elements within the site you can work with using the REST; content, field, users you name it. You can fiddle with any kind of content and configuration on your site.

Conclusions

Decoupled Drupal is a very good technique to be used under the correct circumstances and conditions. It's also a good opportunity for developers to approach new front end framework solutions while still using Drupal. It's up for the developers to overcome possible risks and enjoy the benefits and rewards decoupled Drupal provides.