At Chromatic, we love a good decoupled architecture. In fact, we have written extensively about decoupled and why you might want to “decouple” a site. One throughline in our work and writing has been that decoupled isn’t always a slam dunk; you need the right combination of business needs and engineering skillsets on your team for it to be the right solution. The effort can be well worth the trouble if you are distributing content to multiple platforms and have a team large enough to support engineers in the necessary areas of expertise.
But what if your site is already decoupled, and you are beginning to wonder if it was the right choice? Maybe your team decoupled the site years ago, or you inherited the architecture, but either way, that work is long since complete, and you are responsible for maintaining the platform. The question becomes, does the higher effort required to maintain and iterate on a decoupled site still match your product or business goals? A decoupled site can end up feeling like you own a hot rod, a hot rod that requires engineers with two different skill sets to maintain. This can be difficult enough to implement, but hiring for these needs adds a challenge; it’s hard enough to find a talented Drupal or WordPress developer, but finding a unicorn that also has deep expertise with your front-end stack will often be difficult.
Signs You May Want to Recouple
- It’s no longer clear to you what benefit you are gaining from your decoupled site.
- You are only using the API to serve the web front-end application. You are not distributing content to other applications.
- You are having trouble keeping up with maintenance on the two decoupled applications.
Recoupling as an Option
If the above challenges sound familiar, “recoupling” the site back onto a single platform could be a viable solution. You’ll be left with one platform and technology stack to maintain, removing a great deal of complexity in maintenance, product development, and recruiting.
We recommend evaluating the existing back-end platform and determining what it would take to turn the part of your architecture serving an API into your full web stack. With Drupal or WordPress, we are essentially left to create a new customer-facing theme to be served from what is currently the API site. This is no small effort and should be weighed against the support burden of the existing decoupled site. If the tradeoffs make sense, you will be left with a single codebase to maintain, keep up with dependency updates, and iterate on.
We still love building and maintaining decoupled sites, and they are a huge win for the right use case. However, if you find yourself maintaining a decoupled site that feels like the juice isn’t worth the squeeze, it may be worth evaluating if decoupled is still the right answer.
