Differences Between Drupal Progressively And Fully Decoupled Implementations
The functions of a CMS are not limited exclusively to the creation of content. Still, it is also responsible for delivering this content user-friendly to various heads such as websites and mobile applications. For all this, Drupal CMS is so attractive to many companies of the most diverse fields and sizes.
So, in order not to make the introduction long, we can divide the possibilities of decoupling Drupal CMS into two possible main approaches (I recommend reading the Headless CMS article) depending on how the different areas of a company are going to interact with the content and the particular rules that each one of them imposes: progressive and fully decoupled.
Fully decoupled Drupal
Fully decoupled Drupal refers to the complete separation of responsibilities between the presentation layer (regardless of the number of implemented front-ends it has) and all other aspects of the CMS.
This approach is highly recommended (among other possible reasons such as security, scalability, etc.) for high-availability implementations with low-cost infrastructure, where the Drupal CMS becomes a data provider and a JavaScript front-end application, or almost a static websites generator, that communicates with Drupal via APIs.
Fully decoupled Drupal runs in two ways: fully decoupled application and fully decoupled static site.
- Fully decoupled applications are the most widely used approach today and are preferred by many developers. These use frameworks like Angular, React, and Vue.js during the decoupling process and are written in JavaScript.
- Fully decoupled static sites help in improving performance, the security and reduce the complexity for developers. A static site generator like Gatsby enables retrieving content from Drupal, generating a static website, and deploying that static site to a CDN, usually through a specific cloud provider.
Although this approach lacks “critical” features like in-place editing and content layout management, fully decoupled Drupal is always the first choice for developers who tend to seek better interface control (fewer permissions, types of specific content for each page) and that have teams with extensive experience in creating front-end applications based on JavaScript frameworks or libraries such as Angular, React, etc.
Progressively decoupled Drupal
Drupal progressively decoupled is more of an architectural approach than a simple way to implement a CMS. Using the Drupal rendered and API endpoints together combines the best of both traditional and fully decoupled approaches.
This approach is especially recommended for web components-based front-end applications. It allows website authors and publishers to take advantage of administrative interfaces, workflows, and many other tools for creating, editing, and publishing content for the front-end application.
It balances editorial and development requirements properly by allowing website authors and publishers access to contextualized interfaces, content workflow, work-in-progress previews, and other important features. Additionally, through this architectural approach, frontend developers access the different structures of the pages under construction, possibly including advanced functionalities through frameworks and libraries such as React or Angular. This process helps front-end developers by removing the restrictions of the Drupal CMS template system.
What should you choose?
Now that you are familiar with both the Drupal CMS decoupled approaches, which one should you go with?
It only makes sense to go with fully decoupled if your project also reflects editorial needs. On the other hand, if your project requirements are full of development requirements, progressively decoupling is not the best choice. The following table will give you more clarity on which is the best choice for your new application.
Summary
Organizations aim to create interactive and omnichannel user experiences through their website. Drupal CMS provides them the flexibility to innovate, gives limitless options on what they can create, and empowers them with the ability to power multiple websites and applications. But there are other ways to achieve this goal than fully decoupled. Your organization can have the best of both worlds by using a progressively decoupled implementation. This article tries to simplify or at least collaborate with some information on what architecture approach is the best for your organization.
