Fully decoupled or progressively decoupled
For those of you whom the word Decoupled doesn't mean too much, I will try to explain in a few rows what it means. Then, of course, I will also provide some other reliable sources of more information.
WHAT'S A DECOUPLED CMS?
Decoupled or headless CMS means a content management system without an interface which exposes its content through REST services.
Basically, the concept is called Headless CMS but in the Drupal community, this has been transformed into Decoupled CMS, Decoupled Drupal. Either Decoupled or Headless, we're talking about the same thing.
In Drupal, the Decoupled concept started to be more predominant once Drupal 8 was released.
Why?
Because among those 200 new functionalities and improvements in Drupal, the REST services, included in core, became more flexible and were extended much more than they were in Drupal 7.
From this point on, the range of possibilities became wider in terms of user experience. This happened because using a javascript-based interface facilitates the creation of so-called "one-page" sites or "application like" sites.
Things seem simple and we think about the interesting projects that we can create. Still, when the time comes to actually work on a Decoupled project, we realize that there are no endless possibilities because we will lose a lot of features and options available in a CMS which we generally take for granted.
DECOUPLED OR PROGRESSIVELY DECOUPLED?!
Next I would like to share a different point of view related to Decoupled CMS (Drupal), the System architect's point of view.
As a System architect, I have to find the right solution both technically as well as financially so that the project can be implemented. Generally, a CMS is the right choice as a starting point when designing and implementing a web project because it comes with a set of features that allow the project team to spend most of the budget for particular and specific features.
These are the ones that bring actual value to the project. Also, these are the ones that the client appreciate in the project.
I mentioned CMS features that we as programmers take for granted. Well, these functionalities actually make the difference and weigh a lot when as a System architect you need to decide how the project is going to be implemented.
For example, a fully decoupled project won't benefit completely from the built-in cache mechanism of Drupal. Caching can be implemented for the REST services but this takes time, so we will have an extra cost.
I am sure that most Drupalists know the iconic modules from the "Field management" category like “Paragraphs” or “Field Collection”. These modules extend the field creation built-in options from Drupal forms by offering the possibility to group fields of any type and manipulate them as any other entity.
Using these modules the content types become more dynamic and this means that we can reduce the costs of the implementation.
Not using the CMS interface (by implementing decoupled) these options do not exist anymore and implementing them from scratch will add extra costs.
INFORMATION SECURITY AND DECOUPLED
A very sensitive topic even when we talk about a CMS. Implementing Decoupled, we need to pay much more attention to information security. Also, we need to implement extra access control options to the REST services. Of course, the core services and the ones exposed by the "Views" module can be controlled through the built-in permission system. However, a custom service will require custom security as well.
The communication between the interface and the CMS must be secured as well using protocols like OAuth 2.0.
When we pitch a Drupal project, often we bring into the discussion the fact that with Drupal is very easy to add new fields or to change options of existing ones even by the client and this info makes the client more interested in our offer.
This detail was actually considered an advantage in project negotiations. Implementing Decoupled, we will not advertise this possibility anymore because it won't be available by default. In order to have it, we need to invest some amount of time to build it. Not to mention what's the feeling when the client asks about this possibility from his own initiative...
DECOUPLED TECHNOLOGIES AND TRANSLATION
Another important option in Drupal is the interface translation. Drupal includes an advanced mechanism for translating the interface (and the content). In Decoupled this needs to be built from scratch. What does this mean? Extra costs...
I could go on forever with this kind o examples and I could get asked if it is really worth implementing a Drupal Decoupled project.
The answer is YES, it is! But when there a budget limitations or when the client is not interested in the implementation technique, unfortunately, you have to choose wise and efficient. In this case, a CMS (with back-end and front-end, meaning Coupled) is the best option.
MODERATION MAY BE THE KEY
Personally, because I am interested a lot about Decoupled but also because I have to make sure a project can be implemented within a budget, I go for a moderate approach.
When a dynamic experience is needed in a project I put myself and the projects in the Progressively Decoupled area.
I try to design the regular features in a way that the back-end and front-end of the CMS can be used and for the "sensitive" sections I add a Decoupled approach to the plan. A quick example of such a project would be a site for an insurance company.
This site would feature a price calculator among other sections with information from the insurance industry and maybe give the users the option to create their own accounts.
The price calculator can be implemented in a framework like Angular and the rest of the site can be implemented in a traditional manner with the Drupal CMS.
DECOUPLED DOESN'T EQUAL RESPONSIVE
Finally, I would like to point that I also noticed a false assumption circulating among people about the fact that a Decoupled approach helps a lot or it is the only way to obtain a "responsive" website.
This is not true. Actually, I could say that a CMS front-end is much more helpful as it is also on the SEO side because in general CMSes are optimized for this and offer a lot of options.
So don't be afraid to start a Decoupled project and if you there are any constraints, feel free to try a Progressive Decoupled approach. This is how I would do it...
More info can be found here:
