At Brightspot, we believe in front-end freedom of choice—to be able to choose the architecture that best suits each individual organization’s unique needs. That’s why we’ve designed Brightspot CMS to operate as a traditional, decoupled, headless or hybrid CMS solution.
David Gang, CEO & Co-founder, Brightspot
Today’s consumers take in their information in a variety of places: from the web on a desktop, on wearables and via apps. Small businesses, website owners and marketing teams are challenged with creating and dispersing content that can be used across multiple platforms and easily digested by a customer.
However, a business may find their content management system (CMS) limits their ability to distribute content while keeping the information all “under one roof.” This is where a hybrid CMS comes in and may provide the solution your business needs for more efficient content management.
Hybrid CMS explained
What is a hybrid CMS?
To better understand what a hybrid CMS is, it helps to look at the three main category types of CMS:
A hybrid CMS approach combines both decoupled and headless architecture. It lets your company create and manage a breadth of content, plus deliver it to a variety of channels, from websites to mobile apps—all without sacrificing any user experience (UX). It means the UX is the same across any device or application. The flexibility inherent in being able to choose either a decoupled or headless path as business needs dictate means a company is not forced into one option that might then require complicated and costly re-engineering down the road.
- Traditional CMS: A traditional CMS supports a website (and minimal other applications) with coupled front-end content delivery and back-end content management. An example of this is WordPress. Websites hosted on a traditional CMS platform like WordPress are served from one single system, providing a simple way to manage content and the user experience from one place. For many use cases, this mitigates the need for deep technical expertise (although it's an architectural approach that also means drawbacks should changes or sophisticated customization be required).
- Decoupled CMS: A decoupled CMS means the front-end content delivery is uncoupled from the back-end content management. A decoupled CMS allows its users to work with templates, which means you can deliver content quickly and to a variety of channels. However, this CMS is often more complicated and requires more specific back- and front-end engineering resources to manage.
- Headless CMS: A headless CMS is a variation of the decoupled architecture. It does not connect to the front end, rather it only deals with the content. The content is published through an application programming interface (API), which can push the content to any device, website or app.
A hybrid CMS approach combines both decoupled and headless architecture. It lets your company create and manage a breadth of content, plus deliver it to a variety of channels, from websites to mobile apps—all without sacrificing any user experience (UX). It means the UX is the same across any device or application. The flexibility inherent in being able to choose either a decoupled or headless path as business needs dictate means a company is not forced into one option that might then require complicated and costly re-engineering down the road.
What are the advantages of a hybrid CMS approach?
One of the biggest advantages of a hybrid-headless CMS architecture is its ability to reuse content in multiple places. It gives you, the publisher, the ability to mix presentation or front-end choices. You can deliver a different user experience based on the consumer’s device or browser, which means they have the same experience no matter where or how they’re consuming the information.
In addition, a hybrid CMS offers greater speed to market. Since the content and presentation are separated, each author can work on his or her publication independently, allowing an accelerated timeline to complete content tasks. Speed-to-market is also conferred by the nature of the fact that future development is not limited by the choice of what CMS architecture was selected at the beginning of a project. The choice is not binary, meaning a business can approach it with the content problems it is trying to solve at that point in time rather than based on a specific technology solution it implemented at some point in the past.
In addition, a hybrid CMS offers greater speed to market. Since the content and presentation are separated, each author can work on his or her publication independently, allowing an accelerated timeline to complete content tasks. Speed-to-market is also conferred by the nature of the fact that future development is not limited by the choice of what CMS architecture was selected at the beginning of a project. The choice is not binary, meaning a business can approach it with the content problems it is trying to solve at that point in time rather than based on a specific technology solution it implemented at some point in the past.
What are the disadvantages of a hybrid CMS approach?
A hybrid CMS will require a decoupled or headless API in order to structure for full content management, which may mean additional resources are necessary to develop, deploy and manage. It also takes additional setup and maintenance, focusing on both the front-end and back-end code.
So with a hybrid CMS, it will require bringing together the feature set, architecture, technical team and customer base at the outset to ensure resources are available to implement and support. However, this up-front investment will offer greater rewards, flexibility and future-proofing over the long run.
So with a hybrid CMS, it will require bringing together the feature set, architecture, technical team and customer base at the outset to ensure resources are available to implement and support. However, this up-front investment will offer greater rewards, flexibility and future-proofing over the long run.
If a developer wants to modify the way the [Brightspot] platform operates, they can do that. If they just want to build a lightweight application on top of that, do that. If he or she just wants to publish content or use the existing theme infrastructure, then go that route.
Dan Slaughter, Chief Architect, Brightspot