Time to breakup? Three reasons to decouple your application

We’ve talked a lot recently about decoupling websites: what that means and different ways you can do it on Platform.sh. Now let’s take a moment to discuss whether you should decouple in the first place.

The truth is, in many cases you shouldn’t. There are valid reasons not to decouple your website, such as:

• The need to rewrite your existing content to keep that content API abstract enough to decouple
• The need to rewrite your custom code to match CMS features you’re used to working with
• The need to maintain that custom code
• The risk of complicating your architecture

But there are also many compelling reasons to decouple. Here are three big ones to consider.

Decoupling gives you the flexibility to choose specialized frontend frameworks

CMSs are specialized for managing content. Anything added on top of that functionality, like presentation, is just that: an add-on. Add-ons are not what Drupal was necessarily made to do, only what it has grown to support.

On the other hand, JavaScript specializes in presenting content on the web. From React to Vue to Gatsby, modern frontend frameworks continue to improve in speed and flexibility in a way a theme add-on system can only support so much. This is where a big advantage comes for decoupling: specialization of tools.

Decoupling allows Drupal, WordPress, or a specialized headless CMS like Strapi to focus on the single task of managing your content—nothing else. That frees you to dedicate a whole application to just the presentation demands of presenting your content on multiple devices. Since you’re choosing the best tools for the job, you never hit the upper limit imposed by monoliths for a particular function. If a specialized frontend framework hasn’t already solved the problem, you can be sure a community of developers is cooking up a solution.

Decoupling enables focused teams and better recruitment

This second reason to decouple lies on the other side of the “specialization” coin above. The freedom to choose specialized apps also brings the freedom to choose specialists for your development team.

Say you have a Drupal 9 site with a bug in a JavaScript plugin that results in formatting weirdness on tablets. Your team’s specialized for PHP rather than JavaScript, so the task will be a greater lift than it would be if your team included a JavaScript developer.

But a decoupled site would enable you to expand your recruiting to a JavaScript specialist who could focus on problems like this on your frontend, making your site look the best it can be.

That opportunity to focus is a key benefit of decoupling. Frontend devs focusing on the frontend app, backenders focusing on supporting the CMS, and writers focusing on creating content on top. So long as the API between it all is clear and stable, you can maintain a pretty strong separation of concerns between specialized teams.

Decoupling lets you “Create Once, Publish Everywhere”

The last big reason to decouple has become increasingly relevant as the variety of Internet-connected devices has exploded. Decoupling a CMS into two apps lets you dedicate specialized teams to focusing on how that data is presented on a laptop. But what about on mobile devices? Tablets? Gaming consoles? IoT devices?

All of these come with their own delivery and presentation concerns that without a doubt would add too much responsibility to a monolithic app. Good news is, once you’ve decoupled your data sources from presentation and created a solid API they can communicate over, you could very easily develop additional applications that consume the same data. Each app uses the same API, gets the same content, and concerns itself only with how it will all appear in its own domain.

This is the “Create Once, Publish Everywhere” concept you may have come across. You turn your previously monolithic CMS into a data store and API, which frees you to develop all kinds of things on top that consume that content. Technology, constantly changing as it is, will likely turn out another platform or device you’d like some kind of presence on. Once you decouple, you’re one step closer to getting your content there.

The number of companies deciding to decouple their applications testifies to its advantages. Are there downsides to the decision? Of course. Should every site decouple? Certainly not. To help you decide where and when to decouple, we’ll continue to explore the topic in detail.

In the meantime, take a look at our documentation for more information on the decoupling solutions that are supported by Platform.sh.