·¬ÇÑÉçÇø

With a headless implementation, back end and front end developers can be working on their parts of the project concurrently. The key to this is making sure both sides have laid out their requirements ahead of time. Once that's established, "I can develop my models not thinking about how the front end is implemented," says Axel Tarnvik, a back end engineer for Brightspot. "As long as I'm adhering to the plan we've established between front end and back end, there's no work for me to go in and make sure the front end can handle the data."

Because a headless CMS doesn't dictate the user interface, front end developers can use their favorite frameworks and tools, which can change over time and with different projects. The front end can change completely without the back end even knowing about it, which makes it easy and fast to integrate new designs. "You have less reliance on the back end making changes once you have an API set up," Tarnvik says. Even before that point, Eckels says, "We can mock data on the front end and start running so the back end doesn't need to be ready for us. We can just go."

As long as a headless CMS has some way of communicating with a third-party vendor (examples include Facebook, Getty Images, Salesforce, and Slack), they can integrate. "If a third party just needs to depend on an API, with a good headless implementation, it could be no work on the CMS side of things," Tarnvik says. Some data might need to be massaged if a partner has very rigid output requirements, he adds, but a headless approach offers a good starting point in those cases.

It's unavoidable in digital: The moment you've gotten things running smoothly, something changes. New devices emerge, partners evolve, business strategies pivot. A headless CMS makes it simpler to adjust content without creating massive headaches for developers, because the back and front ends aren't locked together. With a solid API in place, Tarnvik says, "You can be ready for new devices a lot quicker because they can just interact with something that's already there."

The modular approach of a headless CMS likewise means you're far less likely to have code that's customized for a specific CMS implementation with a specific front end attached. If you have a CMS that supports headless, you won't need to try to retrofit the back end to accommodate a new channel downstream. At the same time, you'll be able to repurpose front end code that you like for different projects and even a different CMS, as long as that CMS supports headless.

If you'd like to learn more about headless CMS architecture, check out our this webinar, where we dive into even more detail.