Drupal 8 – The future is decoupled

    Digital content has evolved to multi-format and multi-channel distribution, while we expect to be able to consume it anytime, anywhere. But how is this changing WCMS such as Drupal? Find out why the future of Drupal is decoupled and what it means for authors, administrators and users.

    Subscribe to our blog

    A decoupled CMS architecture means having two or more systems that are able to communicate, without being directly connected (coupled). One system usually has very limited knowledge of the other(s). The advantages? A decoupled structure allows changes to be made to one system without affecting the other. This means more flexibility when it comes to reusing the same content for different interfaces and a future-proof CMS that will easily adjust to any emerging channels.

    With a decoupled CMS architecture, we also split the responsibilities between both layers (see figure below). The systems that consume content don't need to care about the data architecture, security, infrastructure and other factors, and the data provider (the web service, in our specific case the "decoupled Drupal" instance where content editors work) doesn't need to care about the front-end technology, layout and so on.

    When we translate this into the typical Drupal set-up, it means we basically draw a line between the presentation layer and the content administration of Drupal (front-end vs back-end). This is also called "headless CMS", in this case “headless Drupal”, as users typically don't see the "head", or theme, of the Drupal CMS installation.

    The future of Drupal is decoupled and what it means for authors, administrators and users.

    In this set-up, Drupal acts as a data provider (content service) only. Via web services (a type of communication mechanism between different software applications) it provides content in its raw format. It's up to the consumers of this data (the systems which use the web services) to manipulate and visually present the data. As an example, the Drupal instance provides plain data about events via a web service. Two potentials consumers could be an iOS calendar application and a website listing all the events. In this case, both consumers (the app and website) retrieve raw (textual) data. They need to manipulate (filter the info they are programmed to display) and apply their respective stylings (e.g. create html markup, apply CSS, etc.).

    Why decoupled Drupal?

    Up until version 7 of Drupal (2009), online content consumption was pretty much limited to browsers on desktop computers. With the rise of touchscreens and portable devices such as smartphones and tablet computers, mobile online access progressively caught up with and even surpassed desktop in all kinds of ways, leading to a shift of digital channels towards a "mobile-first" approach. The default presentation of content was no longer tailored to the large computer screens, but optimized for all kinds of screens: from phones, to tablets, to televisions and anything in-between. Making the content not only available but also fully functional and optimized on all screen resolutions was, and is still, a top priority.

    In recent years, however, we see a large amount of alternative ways to display content, varying from different JavaScript frameworks, like AngularJS, ReactJS, Vue.JS.., native Android or iOS mobile applications to small widgets that only pick up small bits of content to surface it on other interfaces.

    If we want to achieve this in Drupal, we need to (fully) decouple the content model from the templating engine (Twig in Drupal 8) so that content can be exposed to the consumer system of choice.

    This principle leans on what we call "COPE" - “Create Once, Publish Everywhere“ -, a concept similar to single-source publishing that means all content is managed in a central repository (Drupal back-end) and distributed across all channels (either pushed or pulled when they need the data).

    A future with API-first or decoupled by design?

    Within Drupal 8, we already have basic support for REST services for data exchange. But the REST API is hard to set-up and configure. For full decoupling, Drupal still needs a bit more development, and there are two community-driven initiatives currently building upon this topic.

    The most important and concrete one at the moment is the "API-first" initiative, led by Wim Leers. Contributors to API-first are working hard to enhance the currently available REST API, which they pledge is going to be the "best-in-class". With more flexibility, it aims to support new types of integrations, progressive decoupling and full decoupling. The end-goal is to make all data within Drupal available in both:

    • a RESTfully way, supporting JSON or any other REST service format beyond the default
    • a non-RESTfully way, like GraphQL or CouchDB for example
    • using any authentication mechanism out of the box both for websites and native mobile apps, like OAuth2 and Cookie among others.

    In the next releases of Drupal we will see a lot of movement coming from this initiative. Most new functionalities are striving for a "stable" contributed module so they can move along the path that needs to be followed to be introduced to Drupal core. This means it has to be available for all Drupal installations to be added as an add-on module. If the core committee makes the decision the functionality can move to core, they are sure there's already a stable release ready and tested.

    All of the above allows Drupal to be used as a headless data provider, but it still starts from a completely coupled installation at first. With all the momentum around decoupling, would it be possible that Drupal moves towards an API-only, rather than API-first, or a fully decoupled by design architecture? There certainly is a market for this approach, on the front-end development side, which we talked about above, as well as on the back-office administration side.

    A second initiative approved by the committee is looking at a way to modernize the current back-office pages, which date back from years ago and only got a responsive overhaul lately. Their current approach (or proof of concept) is to replace this page by a single-page React application. While this is at an early stage and there's a lot of work to be done, it certainly is interesting to see Drupal core making a decision like this.

    There are some additional question marks popping up, that we expect will be answered as we progress in this direction:

    • What happens with the current templating engine (Twig)? Will both Twig and the React application work side by side? Will Twig be "optional"?
    • There are hundreds of contributed modules, do they all need to add support for a "decoupled" interface, or will they fall back on Twig?
    • Is it a good idea to make a fixed choice for one framework (React) in core?
    • Will there be a fully decoupled Drupal installation profile?

    In the end, the goal is to create a decoupled CMS architecture, but still provide a monolithic experience. Users, authors, administrators don't care whether a site is decoupled, rendered by Drupal or is static HTML. They want their experience to be as fluent and as consistent as possible, while developers want the maximum possible flexibility.

    Published on 13/08/18    Last updated on 16/08/18

    #Drupal, #Web Development, #CMS, #Digital Strategy

    About the author

    Kevin is Drupal Web Developer and Consultant at AMPLEXOR based in Belgium. Kevin is an Acquia Certified Developer with over 6 years of experience in planning, development, maintaining Drupal websites and leading development teams in Drupal. He has also volunteered at the organization of the yearly Belgian DrupalCamp event.

    SUBSCRIBE TO OUR BLOG

    Participate in this discussion