Websites have become a necessity in the 21st century. From gathering traffic on them to creating a buzz about its brand and resultantly leading to a higher sales figure, websites can do it all. However, not all websites are able to do that. A successful website is often considered to be one with the best user experience and performance. A low bar at these may just be the doom of the site developers. And when you combine the impressiveness of the site’s UX and performance with its overall aesthetic and product quality, success is almost guaranteed.
So, the process of building a website has to be done with the utmost care and expertise because doing a half-hearted job at first and regretting it later would not be prudent for anyone. The build and functionality of the website entirely depends on its developers and the CMS at work. Choosing the right architectural approach should be the first priority for all business owners and site builders.
Getting into the architectural aspect makes me highlight the two variants that are the most popular amongst Drupal websites, the monolithic or the traditional architecture and the decoupled architecture. This article will accentuate all the areas of these two and discuss their aptness for different business needs..
Introducing the Contenders: Monolithic and Decoupled Drupal Architectures
Drupal is a pretty versatile content management system, it has the capability of building your websites for you, taking care of each and every aspect of the same. That should sum up Drupal’s capabilities, yet it doesn’t. With its different forms of architectural options available, Drupal has become the embodiment of versatility. The choice of deciding between Monolithic and Decoupled forms of Drupal architecture is proof of just that.
Starting with Monolithic architecture, in the terms of a software engineer, it means a single software that has the potential of handling every aspect of work done on it or with it. A monolithic architecture will always be single-tiered, wherein the UI and the code for data access are merged into one platform. And that is what Monolithic Drupal architecture or the traditional Drupal architecture means. The coupled Drupal is well-equipped to make a website up and running, both in terms of the front-end and the back-end. You would not need to rely on anything else, if taking the Monolithic approach. You would have all the Drupal resources in your corner, as your project would be entirely nestled inside it.
Drupal is regarded highly in the community for its back-end capabilities, its front end deserves equal regard. Using Drupal’s many behaviours, themes and templates, you can easily create impressive visual designs that would also provide state-of-the-art interactivity to your presentation layer that can be customised on the go. And there is more, any problem with your site’s design, behaviour, usability and management can easily be tackled by Drupal’s frontend aspects. So, it won't be wrong to presume that the traditional Drupal is a versatile software easing the process of building web applications.
However, if you want to tap into the other frontend technologies, then there is a possibility for that as well, with the use of Decoupled Drupal architecture.
In simple terms, decoupled Drupal architecture separates the front end from the back end. The Decoupled Drupal separates the UI from the presentation aspect. Although the UI and the content management would be provided by Drupal, you would have free reigns over the presentation layer. You would not be bound to use any of the themes and templates. This approach mainly needs Drupal to act like its content repository. Although it is a relatively new trend in the CMS, many all over the Drupal community have taken it up. It has been gaining more and more traction because of the freedom Decoupled architecture provides to its users offering the advantage of capitalising on the many front-end technologies available outside of Drupal. Learn everything about Decoupled Drupal here.
In essence, both Monolithic and Decoupled approaches can be deemed similar in the sense that they have the back-end Drupal technologies. However, when the front-end or the presentation part comes to play, they start to seem vastly different.
Different Ways of Leveraging Decoupled Drupal Architecture
Now that we know how the traditional and Decoupled Drupal architecture are different on the foundational level, let us delve deeper into the different ways of decoupling Drupal architecture.
Drupal was founded as a monolithic software performing every aspect needed for website development. This architecture has total control over a project, in terms of its presentation, all the visual elements along with in-place editing and layout management as well as in terms of data. In an attempt to not sound like a broken record, I would add that Drupal in its traditional sense is still the most used version of the software primarily because of the control it gives to the editors.
Coming to the Decoupled architecture, the story changes. Like I have already told you, the Decoupled approach mainly relies on Drupal for its backend capabilities, the front-end may or may not entirely become independent of Drupal.There are two broad categories of this architectural approach.
Progressively Decoupled Drupal Architecture
Fully Decoupled Drupal Architecture
In a fully decoupled Drupal application, you see a full separation of the presentation layer and other elements of Drupal.What this means is that the client’s framework becomes a server side pre-renderer, which ultimately leads to uninterrupted workflow. The CMS is a data provider in this instance. And an API layer acts as the connection between the two, retrieving data from the back end and providing it to the front end. It has to be understood that many Drupal features like in-place editing will lose their functionality or rather become unavailable in this approach. However, you will be able to exert a great deal of control over the presentation layer with other available technologies, React, Angular and Gatsby being a few of them.
Being API-first CMS: Drupal Web Services
Like the name suggests, being API-first means building an API before building a web application, which is basically created around the former. For the Decoupled applications to work effectively, Drupal has to be equipped with a top-knotch API that would essentially be the thread holding the front and backend together. The Drupal community has done a great job in this matter.
The provision of pretty impressive web services that have been years in the making are proof of that. REST API can be considered as the paradigm here, however, for the applications that do not communicate using it, Drupal has other web services modules as well. Since Drupal was able to provide these and transcend the degree of functionality provided by REST API, it is all set to become the best open-source API-first CMS.
Primarily, the Decoupled Drupal has been known to use any one of the three APIs I have mentioned below. I would like to add that since the Monolithic approach does not need an API to provide a connection, these would not be relevant while using it.
REST or Representational State Transfer API is one of the most popular ways to let the HTTP client get the responses it wants from the content repository, which is Drupal. Drupal provides this web service out-of-the-box that includes RESTful Web Services, Serialisation, HAL, and HTTP Basic Authentication. With its proficiency at executing HTTP requests and responses, it easily aids in operating the data managed by Drupal, be it comments or nodes or maybe even users.
In a simpler sense, REST API is like a mediator along with the HTTP client because they help the front and backend to work harmoniously on any framework they like.
JSON:API is gaining momentum as the go to mediator in the Decoupling process of Drupal. A reason for the same is the fact that it is the better version of REST API. It offers a relatively high degree of productivity in comparison to REST API with minimum requests to the server and providing related resources without asking. It is phenomenal at filtering, pagination and its sorting capabilities along with caching use are almost impeccable. You tell me how can it not be the go to option here?
GraphQL is a query language that was developed by Facebook. It is used for custom queries to retrieve data from the backend with a single request. The GraphQL Drupal module works on the same principle and even lets you update and/or delete content or an entire configuration. Moreover, GraphQL has the ability to act as a base-line for the generation of custom coded schema or its extension. I find this one detail to be really helpful when the plugins are to be used to form a sub-module.
Check out more alternatives on the modules available in the decoupled Drupal ecosystem here.
Let us have a look at some of these.
React is known to deliver the most amazing digital experiences when it is combined with Drupal. With big names like Facebook, Reddit and Airbnb as its users, it does not come as a surprise. React has the ability to split a code in varying components, which is immensely helpful in debugging and enhancing the reusability of the code. If you want to produce results that are both SEO friendly and very responsive, then React is the perfect option for you.
Angular was initially introduced by Google in 2009, but the 2016 re-released version was entirely rewritten to make the development of mobile and web applications very easy. This is especially true because it uses HTML in the simplest form to clearly define user interfaces, eventually making web applications a trifecta, interactive, functional and extremely hard to break. Perhaps, this is why The Guardian and Gmail are proud users of Angular for their frontend aspects.
Static Site Generator
A Static Site Generator or an SSG is a tool that is used to build static websites which have a pre-existing set of input files. It is often regarded as a middle ground, wherein a hand-coded static site is used with an CMS. There is one particular SSG that deserves to be mentioned.
Metalsmith is one of the simplest SSGs to be used and it is pluggable. It can effectively produce static build files by extracting information from the source files, manipulating it and writing it to files in a destination directory. These indeed seem to be a lot of files. From grouping files to translating templates, it can perform numerous manipulations, all using its plugins and all consecutively. Not only does the use of plugins simplify things, but it also provides the user the liberty of choosing and implementing only the ones that he needs.
Tome stores your information in static JSON files, which are generated from static HTML form your very own Drupal site. With Tome, you can choose from the large number of themes and modules found in Drupal, create content and simply push the static HTML to production and your work is done. The fact that it allows you to use Drupal without any security or performance worries is another bonus.
All of these are regarded as the top-notch front end technologies for web building and you may very well know that nothing can beat Drupal at its back end game, so with Decoupled Drupal you get to have the best of both worlds, the worlds inside and outside of Drupal.
On the contrary, if your project mandates the use of JS or static site generators, the traditional approach will not cut it for you. Decoupled Drupal has to be taken up and there is no harm in that as well. There are so many big names, like the Weather.com, NBC and Warner Music, who have been using the Decoupled architecture and they have experienced great results.
Whatever approach you may think you want has to be aligned with the needs of your project. And when they do, trust me, whichever approach you will choose, it would be a winner for you.