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:
But there are also many compelling reasons to decouple. Here are three big ones to consider.
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.
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.
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.
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.
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.