Frontend frameworks

Decoupled/headless content management systems (CMS)

Decoupled architecture and headless websites have been gaining popularity among our clients since the release of Drupal 8 with built-in REST services. The idea that your website's data can be shared through an API to provide up-to-date content in more ways has clients like Victoria’s Department of Premier and Cabinet (DPC) recognising the added value it brings. DPC’s Single Digital Presence platform uses Drupal and Node/Vue in a decoupled architecture to build out its websites, with the goal of cross-site content sharing.

But what are decoupled websites? How does it work?

Decoupled architecture

Layered architectures are popular throughout computer science. If each layer of a technology stack is independent of one another, then one layer can change without affecting the others.

In a decoupled architecture for Drupal, we are decoupling the data/logic and the application layer. Traditionally for Drupal data is collected from the database, logic is applied, markup is generated, and the resultant HTML is returned to the visitor. But when decoupled, Drupal is only responsible for collecting data and applying logic. From that point, the data is then passed to a separate application layer for generating the visual presentation and functionality.

This separation means that the site's application or data layer can be swapped or changed without changing the other. Additional application layers can also be integrated into the same data source - e.g. you could return the site data as a mobile app, a native desktop app, a voice app, integrate into other systems, etc.

Using Node.js

For a decoupled website, the hosting of both layers is separate. You host a Drupal site for managing the data, and you host a lightweight site for handling incoming visitor requests and turning them into web pages.

This is where Node.js comes in. Node.js is a popular runtime-environment with JavaScript as its programming language. It's lightweight and can be used to power websites in place of Apache/PHP.

In decoupled websites, the Node.js hosts the application that makes the calls to Drupal for data, then generates the markup and returns a response to the visitor.

React.js and Vue.js

For Node.js to render the markup, it's common to implement a JavaScript framework such as React.js or Vue.js. They make it easier for developers to produce complex websites in a structured, manageable way.

Developers will spend most of their effort in marrying up the data structure from Drupal into interactive components (built in Vue.js or React.js) that a user will see, like cards, buttons, menus and so on.

But these frameworks are designed to be run in a browser, not on the server, so we need to introduce an additional "glue" that will render pages on the server, and also on the browser.

Next and Nuxt

Normally, React.js/Vue.js run in the browser, so markup is generated only after the page has loaded. This has some disadvantages:

• Search engines won't index the page data because the data is only available after load.

• Page routing for sub pages needs hacky workarounds like using hashes (e.g. www.mysite.com/#my-sub-page), often causing further issues in search engines.

This is where Next and Nuxt are useful. They are extensions of React.js and Vue.js respectively, and allow the framework code to run on both server and client.

Next and Nuxt solve these problems by making a single page web application behave more like a traditional multi-page website. The page can be entered from any URL address, and the correct markup will be returned to the visitor. From that point, any further page loads are handled directly from the client to Drupal.

This can be seen in the following Vue.js example graphic:

1. A client (visitor) goes to a web page. A page is requested from Node.js.

2. The Node.js server runs the Nuxt code and calls are made to Drupal for data.

3. The data is returned from Drupal.

4. The page is rendered on the server and returned to the client.

5. The visitor clicks on a page link. The client calls Drupal for data directly.

6. Drupal returns the data, and the client will render the new page.

7. Repeat steps 5 and 6 for any subsequent links.

Architecture considerations

Some things to consider when deciding on a decoupled architecture:

• Decoupled architecture requires a lot more upfront effort

• Could the same be achieved with just a single page site?

• Is there any plan for data sharing?

• Is it worth the extra effort?

• What is your budget?

• Decoupled architecture requires a lot more maintenance

• More breakage points

• Slower page loads need multiple caching steps to improve speeds

Decoupled architecture is not suitable for every site, but given the right circumstances it can provide a clean way to maintain centralised data across multiple applications.