The 21st century is a pretty marvelous time to live in. There is so much that can be achieved today with limitless possibilities. There aren’t any inhibitions found in people. If we want it, we get it. I mean the 21st century folks have landed on Mars, so is there anything that we can’t do? I think not.
If you look at all of our accomplishments, you’ll find that technology is at the root of it all. It is the advancements we have made in science that has allowed the present time to be as marvelous as it is.
Talking about all of these technologies would take as long as a year, even if I do it succinctly. So, I’ll not get into it. However, I will talk about one segment of tech that has had a profound effect in the way we surf the web. And it is the web development process.
To be concise, I want to discuss a trend in web development that has aided the developers, designers and project managers to build to their heart’s desire without having to rely on one specific technology, which used to constraint them. It is a trend that eliminates restraint and promotes innovation.
Let’s find out what it is.
The Drupal Prequel
Before I get to the main agenda of this blog, I felt like I needed to talk about the underlying technology, which is Drupal. Being a content management software, Drupal ticks all the right boxes when it comes to building versatile web experiences.
To build websites from the ground up and being completely responsible for all of the site’s aspects is deemed as Drupal being traditional or monolithic. What it means is that Drupal would have total control over a site’s technological stack. The front end and all the presentational aspects along with the back end and all of its data layers would fall within the realms of Drupal. Such use of Drupal is quite sufficient for standalone websites and applications, where editorial needs surpass developers' needs and the former seeks complete control over all the visual elements of the page. With Drupal offering features like in-place editing and layout management, I don’t disagree with wanting such control.
However, what happens when the developers want to start implementing the current technology on the front end? What happens when the site needs more interactivity than before? Wouldn’t React or Angular seem like a better option to achieve that?
I think they would and that brings me to the trend I was talking about in the introduction, being Decoupled Drupal.
Unfettered innovation and Decoupled Drupal
Decoupled Drupal essentially removes the link between the frontend and backend and makes the developers free to do what they want with the presentation layer of the site. The reason for this separation is the flexibility it gives to the architectural development, empowering the front end developers to have total control over the projects’s rendered markup along with the user experience.
It’s not just the control over the frontend layer that motivates developers to push for decoupling, there are plenty of other benefits that make the feat of decoupling too good to give up.
- Building impressive features through server-side rendering or Node.js;
- Securing data through a publicly inaccessible CMS;
- Publishing your content on all forms of IOT devices;
- Increasing the speed and efficiency of work with a clear separation of concerns and duties, less interdependence and less hassle;
- Updating the software becomes quicker too, without any impact on the working of the other end;
All of these advantages of decoupling have made the trend to follow. Depending on your need, decoupled Drupal has the potential of building your project with its inbuilt web services and APIs. REST, JSON:API, and GraphQL are the prominent contenders in this regard so that the flow of information from the front to the back is seamless.
However, decoupling Drupal can also leave you in a bit of conundrum as well. The thing is when you decouple Drupal, you are saying goodbye to many of the out-of-the-box features Drupal offers such as layout and display management, content previews and certain security features. Some of these can be written from scratch by your developers, but there are more than a few that cannot be compensated for.
So, in a situation like this how do you lessen the losses? How do you ensure that you get the unfettered innovative edge on the front end and still be able to reap the benefits of Drupal’s frontend capabilities?
The Middle Ground: Progressively Decoupled Drupal
How to decouple Drupal? There is a perfectly reasonable answer to the decoupling dilemma and it lies in its categories. Decoupling Drupal can be achieved in two different aspects.
- In the second approach, you will separate the presentation and data layers, however, there won’t be total interdependence between the two. By this, I mean some aspects of the front end would be developed outside of Drupal and the remaining would house inside of Drupal. This is called progressively decoupled Drupal architecture.
In the first approach, with a total separation you would have to part with Drupal’s out-of-the-box features on the frontend, there is no going around it. However, when you take up the second approach, which is to progressively decouple Drupal that won’t be the case. You would get to play with other front end technologies, yet enjoy all the functionality Drupal has to offer. More on best frontend technologies for decoupled Drupal here.
You must be wondering how that becomes possible, and let me tell you that.
Progressively decoupled Drupal is indeed the perfect balance between advanced frontend technologies and the powerful capabilities of Drupal. You would not need to compromise on one to get the other. The reference of the middle ground for web development in the decoupled sense is an accurate description of the progressive architectural approach.
But how do you decide whether taking up progressive decoupling is the better choice. The question progressively decoupled Drupal or fully decoupled Drupal can often prove to be quite difficult to answer, yet we have to try. So, let’s do just that.
Think of the Editors or the Developers?
For any web project, be it a site or an application, there are two important players. These are the people who bring the project alive, being the developers, and the people who become the voice of the project, being the content authors and editors. So when deciding whether to go for coupled, fully decoupled or progressively decoupled Drupal approaches, you have to keep them in mind.
For the editors, you have to think about;
- The kind of ease they would need in manipulating page content and layout;
- The kind of in-context tools they would require;
- The kind of accessibility they would need in Drupal’s HTML by default;
- And the kind of previews they would be in need of without custom development
For the developers, you would have to think about;
- The king of control they want over the frontend presentation;
- The kind of server-side rendering they want;
- And the kind data security they want.
Assuming the editors want it all, an ease of manipulating page content and layout, tools like in-place editing and contextual links, the ability to preview unpublished content and a constant access to content. Now, assuming that the developers also require the same kind of ease, with control, with the ability to choose between server-side rendering and Node.js built features, with JSON:API at work and a publicly inaccessible CMS.
OSL and A Progressively Decoupled Drupal Project
We, at OpenSense Labs, have worked with a global brand, Produce Market Guide (PMG) to cater to a specific need by performing progressive decoupling.
PMG is a leading name in the market for producing commodity information, trends and data analysis. A part of the Farm Journal family, but aimed to provide an advanced and enriching experience to its users. However, because of a slow search feature that was becoming impossible.
Other than that, the site was functioning pretty well with Drupal. So, in order to rectify the slow search feature, a progressively decoupled Drupal approach was implemented by OSL. using React and elastic, the new search function was built and this improved the time it took to present the result to mere seconds. Look at the detailed case study for PMG for a clearer picture of the project.
This was one project that made our developers understand decoupled Drupal a lot better. The fact that you do not have to build an entire front end from the ground up is a prominent benefit of the progressive approach. Using JS for just one function, making it as advanced and interactive as possible, and calling it a day is essentially how progressively decoupled Drupal works. And I think there are very few architectural approaches better than this one.
The Final Verdict
I want to conclude by giving you another example.
“Imagine you have a site that needs a lot of interactive elements that would encompass user choices and give the user the option of getting a personalised experience based on his history, with future recommendations. Also, imagine that your site has a lot of traffic and a lot of content to manage for which you are bound to need highly competent content management and site building tools.”
For such a site, neither the coupled Drupal architecture would work, nor would the fully decoupled architecture work. It needs a balance of the two.