Types of Backend Services
©2023 Netlify
As we hinted at above, there isn’t a single type of content service, as you might expect if you were coming from an ecosystem like WordPress. With WordPress, there are plugins that tap into the same database and provide a seamless experience for handling different types of content.
One of the primary attributes of composable systems is that each service tends to focus on its own niche and deliver that offering exceptionally well, though they are limited in scope.
When it comes to websites, the standard backend is a headless CMS. This term is often confusing because a headless CMS does, in fact, have a head (or UI). Editors can sign into their service and edit content, typically through a more traditional, form-based experience.
The “headless” term refers to the fact that it doesn’t know (or care) how you configure or use the content. It could be for one site or 1,000 sites. You can store content for pages, or not, and you can structure that however you want in most cases.
There are a few primary differences between a headless CMS and one tied into a monolithic framework:
Monolithic systems usually have some expected schema structure. Headless CMS are generally as open and unopinionated as an ordinary database.
The content within a headless CMS can only be accessed via its API.
Headless CMS have no opinion on where or how the content is consumed (aside from rate limits).
Contentful is the leading enterprise headless CMS due to its ability to serve content at scale, while Sanity is a favorite among developers. We’ve also been seeing more enterprises using DatoCMS and ContentStack, among others.
There are hundreds of options out there, but the four mentioned above are the most popular among enterprises following composable patterns.
There are also services much less opinionated than headless CMS that let you interact directly with a database, but handle the infrastructure on your behalf.
Most enterprises handle these services manually through the major cloud providers (AWS, Azure, GCP, etc.).
There are also emerging tools aiming to make this a more seamless process, such as PlanetScale, which focused on MySQL at the enterprise level.
One approach that goes back to the early days of static site generators is storing content in local files in the repository, sometimes referred to as Git CMS.
While this seems like it wouldn’t scale, we do see this being used at the enterprise level. It’s such a compelling pattern for developers that they want to bring it into everyday use at major organizations. There is certainly a scale cap on this approach, as file systems are limited and slow, especially at scale.
That said, we really like this approach for storing information specific to the project. Things like style settings, layouts, and other site-specific content that should be configurable by editors can be great candidates for file-based content. Especially if the scale is more predictable and smaller.
Note that if you’re using file-based content in a significant capacity, be sure to use a digital asset management system to serve assets. It is not recommended to store assets within repositories.
There are a number of other types of providers that have spun off services that may have previously tied into your monolithic database. Product databases (for e-commerce sites), personalization information, and form submissions are a few examples you may have previously handled within your system, but now are better suited to a specific service provider.