Enterprises aiming to create interactive, and omnichannel user experiences through their website, often rely on Drupal’s decoupled architecture. It provides them the flexibility to innovate, gives limitless options on what they can create, and empowers them with the ability to power multiple-sites and applications.
But is going fully decoupled the only way? What if your enterprise could have the best of both worlds? Say, progressively decoupled? How is it different? And what is the right choice for your business?
Here’s taking a look at both these approaches, suggesting what is best, and when.
From Coupled to Fully DecoupledTraditionally, in its coupled architecture form, Drupal functions as a monolithic system with complete control over its technological stack. It owns the back end (data layers) as well as the front end (presentation layer) of your system. This makes it largely suitable for standalone sites and applications with mostly static content. Especially if the project requirements reflect purely editorial needs like:
- Manipulating page content and layout without a developer
- Requirement of in-context tools like in-place editing, contextual links, toolbar
- Previewing unpublished content without custom development
- Having content accessible by default like in Drupal’s HTML
- the backend focusing on business logic and retrieval of data, and
- the frontend focusing on presentation of content
- Control over visual presentation instead of editors
- Server-side rendering or Node.js build features
- Data security driven by a publicly inaccessible CMS
- layout and display management
- content previews, user interface localization, form display, accessibility, authentication
- crucial security features such as XSS and CSRF protection
So then what would you do? Give up on these critical functionalities? Or stick with the monolithic architecture? It depends entirely on what your project requirements are. And supposing your requirements are a mix of both, Drupal has a solution for you too.
Progressively Decoupled Drupal Architecture
It strikes a balance between the editorial and developer needs, by
- Allowing editors and site assemblers for contextualized interfaces, content workflow, site preview and other features to remain integrated with Drupal
Thus one can maintain client-side interactivity as well as create a potentially richer user experience with the use of this architecture.
Explaining this further with the help of an example,
Let’s say you have a music website for delivering music reviews, choosing either of the coupled or fully decoupled architectures will not get you the kind of UX and features you desire.
But using progressive decoupled will. It will provide you the best features of both of these, rendering your website pages progressively. So that the skeleton of the page loads first, followed by expensive UX prone components like “currently playing” or “songs I listened to most in the last week”.
What Should You Choose
Now that you are familiar with both the decoupled approaches, which one should you go with?
It does not make sense to go with fully decoupled if your project also reflects editorial needs. Similarly, if your project requirements are purely of a developers’, progressively decoupled is not required.
Here’s a face-off between the two approaches to give a better clarity on which is the best choice for your business.
No matter what your needs are, Drupal has a solution for you. At Srijan, we have expert Drupal teams to help enterprises assess their current architecture, and identify which decoupled approach is the way to go. Post assessment, we work to set up a complete decoupled Drupal architecture, based on your exact business requirements.
Get ready to deliver immersive online experiences across customer touchpoints. Let’s get the discussion started on implementing decoupled Drupal for your enterprise.