Content Management Systems (CMS) for developers: An introduction

Imagine this: It’s a sunny morning, you get your first coffee and prepare yourself for the first user story of the day that you will implement in your role as software engineer. It reads like this: “As a user, I want to reset my password…”, and another one: “As an admin, I want to edit articles …”. Your heart sinks. Your creativity withers. Is this what you signed up for when you dreamed of solving complex and meaningful software problems?

There are usually more urgent issues than to implement functionality for the 100th time. One pain reliever could be just around the corner: Content Management Systems (CMS).

CMS have become wide spread tools in modern web/mobile development, offering many advantages for software developers as well as content creators. These platforms streamline content creation, management, and publication processes, allowing developers to focus on more complex and exciting coding tasks. This post will explore how leveraging a CMS can significantly boost developer productivity and happiness. In addition, I will compare different CMS to each other and propose criterias for a selection.

Overview of CMS types and functionality

The core aspect of every CMS is to provide and enable the creation of content. Similiar to the process of creating tables in a database, collections have to be created first within the CMS which define the structure of the data that can be entered. Most CMS also enable content creators to upload and manage images and/or other media types. In many CMS translations play a central role as well, making the content accessible for different audiences. Users can be managed and permissions be restricted or given.

Despite these core functionalities, CMS could be categorized as follows:

• Head-On vs. Headless: A headless CMS is primarily used to organize and create content which is then provided via APIs to external applications that are managed by other developers. In contrast, Head-On means that the CMS also provides a frontend to consume the created content.
• Open vs. Closed Source: Like with many software toolings, the code can be licensed under a friendly open-source licence or not be available at all. Currently, it seems more common to provide the code openly but limit usability with the use of specific licenses that have to be checked before usage. Strictly speaking, this not really open-source and more a middle ground. Even if the code is licensed under a strict open-source license, setup might be complicated so that additonal services by the software vendor are required.

Other functionalities that is quite common include amongst others:

• Functionality out of the Backend-as-a-Service (BaaS) toolbox: Support for authentification, authorization, database tables, permissions and plugin integration with custom endpoints to make a seperate backend redundant.
• An advanced content editor
• Support for collaborative work on content and documents, such as adding comments and concurrently writing texts
• SEO best practices and support
• Support for detailed structuring and categorization of content
• Simple workflows and automations, e.g. sending emails after a new article was added
• AI writing tools
• …and much more!

Comparing CMS to Backend-as-a-Service (BaaS)

BaaS provides developers with a way to link their applications to backend cloud storage and APIs, as well as features like user management, push notifications, and social networking integration. The idea is to eliminate the need for writing backend application logic and to focus primarily on the frontend by leveraging pre-built backend services. BaaS platforms typically handle server-side logic and database management, reducing the need for managing and hosting these services. This approach can, like CMS, streamline the development process, particularly for mobile and web applications.

After going through some of the functionality available in CMS and BaaS, the similarities become apparent. In addition, many CMS providers also claim rightfully so to be BaaS providers, confusing 🧐.

In essence, the main difference is the target audience: Whilst BaaS offerings usually target developers only and do not offer (m)any features for content creators / other business departments, CMS providers target developers as well as other business departments like marketing. Customizable CMS feel often like BaaS offerings PLUS an easy to use interface which can be directly used by other departments. This is usually not possible in BaaS, as these interfaces are still made for developers! You would need to write admin interfaces yourself. On the other side, BaaS usually are more developer friendly and allow for instance more database customizations and easier developer workflows than it would be possible in CMS.

To give you a rough idea, lets visually compare supabase (BaaS) with directus (CMS):

The screenshots provide a high-level overview between both services: Supabase primarily offers a web-based database client interface, while directus appears more user-friendly for those without development experience.

Advantages for developers

As this blog posts centers around developer productivity, lets look at some of the benefits for us software developers:

1. Focus on your core feature instead of monotonous problems: Developers can focus on business critical problems instead of writing for the millionth time user management and other ubiquitous functionality appearing in nearly every project.
2. Ready to use APIs: APIs are provided out of the box and can be used in native mobile apps as well as web projects. This greatly increases productivity.
3. Customizability: Despite the functionality provided out of the box, many CMS providers allow custom extensions. Overall extensibility differs from service provider to service provider, but often even custom API endpoints are supported.
4. Empowerment: With an easy configurable content platform, business departments responsible for content creation are no longer blocked by developers and can now manage their own domain. Therefore, developers are less interrupted with recurrent coding tasks. Obviously, some restrictions might apply: The creation process of the data collections and naming should be standardized in close cooperation with the development team.
5. Hosting / Availability: An important part of software development revolves around the question of how to make the software artifact available. This includes deployment operations and the service of hosting applications. These needs are often provided by the CMS provider, especially when opting for a managed service. Adding new features or endpoints typically doesn’t require hosting separate applications and can often be done within the existing CMS framework. However, the extent of this capability may vary depending on the specific CMS and hosting solution chosen.

With all these advantages given, lets look at how to actually choose a CMS.

Selecting a CMS

The first step before selecting a CMS is to think about your own requirements. Should the CMS be hosted, or should it be deployed in your existing application landscape? Does it have to be open-source or can it be proprietary? Every company and every team might have their own requirements, but here are some criterias to get you started.

Requirements

• Pricing: Based on my current research, pricings can very a lot and sometimes it’s also quite hard to compare offerings. For instance, some pricing models are dependent on the number of translated languages, others just look on pure hardware resource costs. It can be quite difficult to simulate or estimate costs. If you already have an existing CMS you might be able to extrapolate numbers.
• Hosting: For a smaller team with limited ressources, hosting of CMS might be easier and cheaper while bigger teams need to integrate CMS in their own software landscape.
• Open-source licence requirements: Open-source CMS are by nature far more customizable than proprietary software. In addition, no vendor lock-in has to be feared. On the other side, most well maintained projects are not “true” open-source projects and are more a middle ground of open-source and business licenses. The code might be open, but restrictions apply before usage is possible. Therefore, licenses and payment plans need to be studied in detail.
• Level of extensibility: Depending on the use case, exetensibility has to be checked. If the CMS should also work as a small backend with custom endpoints (BaaS features), requirements might be different in contrast to a more classical usage as pure content provider.
• Language support for translations: Most CMS enable translations. But some might be more restricted which languages are available and some couple the availability of language support with their pricing plans.
• Documentation: This point is especially important for open-source systems. Its great if the source code is available, but if setup requires hours of testing project settings it can become a very frustrating experience. As a rule of thumb, try to setup the CMS as a prototype and make a small demo setup. If that already requires many hours, maybe its time to move on. Some CMS are improving so fast that the documentation can’t keep up with all the improvements. It depends on you if you feel comfortable with that.
• Developer ease of use: Available docker images, programming language support (e.g. typescript types), database migrations, supported databases, … might all be individual factors that might be more or less important for you.

CMS Overview

This section provides a small overview of prominent headless Content Management Systems (CMS) in the current market. It’s important to note that this list is not exhaustive, given the vast number of available CMS. Initially, my goal was to create a comprehensive comparison spreadsheet of these offerings in relation to provided features. However, this proved impractical due to the sheer volume of features and the rapidly evolving nature of these platforms. Additionally, marketing materials often claim near-universal capabilities, making direct comparisons challenging.

Therefore, this list primarily consists on my own research of going through recommendations and partly tools that I have personally tested, particularly those with available source code.

• Directus: Already on the market for quite some time, directus is a headless CMS with a beautiful UI. Extensibility offers many options from endpoints to hooks. While directus might not be open-source in the traditional sense (BSL, free usage depending of total finances below five million dollars), the source code is still available on github. Directus is build upon PostgreSQL. The documentation is sufficient but could be sometimes more extensive. Types for typescript can be generated with external toolings. Setup is quite easy. So if you are below five millions in total finances, and you are fine that it is no true open-source licence, I suggest to give it a try and play around with it!
• Payload CMS: As a rather new kid on the block, Payload CMS takes a very developer centric approach as it’s being built around Next.js. As one of the very few CMS, its licensed under MIT which is very permissive. It can be configured very freely but currently undergoes a huge overhall. Therefore, the documentation can’t keep up with the speed of releases. In the beginning, the only database supported was MongoDB. Currently, support for SQL-Databases such as PostgreSQL is being added which will significantly increase its popularity. As its completly open-source, it can be either self hosted or provided as a service. Due to the upcoming releases and the volatile state of the documentation, I would sugggest to keep it on the radar and check back later.
• Strapi: Strapi is another popular, headless and open-source CMS. Care needs to be taken regarding the licenses: Components of the project feature different licenses. The enterprise module requires a business license, while most of the community part is licensed under MIT Expat. The project makes use of PostgreSQL.
• Contentful: Contenful is SaaS (Software-as-a-Service) offering that comes fully managed. With its many publishing functionalities and publishable pages its more focused on marketing but also includes many features for developers, like APIs. Pricing, amongst others, is dependant on the number of different languages that you need.
• Sanity: Another SaaS headless CMS with a ton of publishing and content functionality. It also features a powerful search and great support around social media. The editor is available as open-source, but Sanity itself is not.
• DatoCMS: A SaaS headless CMS with tons of content and publishing functionality. It also offers great support for videos even across devices and many different APIs.
• StoryBlok: A headless CMS with extensive developer support across different languages. In content sections, collaborative features like comments can increase team productivity.
• Webiny: An open-source CMS with a modularized architecture, primarily focused on bigger organizations.

Conclusion

The wide availability of CMS toolings is certainly beneficial for software developers. However, the process of selecting a CMS can be both overwhelming and critically important for the long-term success of a project. It’s essential to thoroughly evaluate multiple CMS options with real prototypes before making a final decision. My suggestions on how to start:

• Define your project requirements:
  • Identify key features (e.g., open-source)
  • Assess technical needs (e.g., specific database types, API requirements)
  • Consider developer experience and ease of use
  • Identify target user groups, e.g. developers, non-technical departments, end-users
• Create a shortlist of potential providers, you can start with the services mentioned in this article
• Implement a proof of concept:
  • Choose the most promising provider from your shortlist
  • Develop a small demo project to test core functionality
• Evaluate long-term considerations:
  • Examine the deployment process
  • Assess the ease of database migrations
  • Consider the flexibility for future modifications
• Make an informed decision: Don’t forget to factor in pricing, support and community resources!

Thanks for taking the time reading this giant blog post 😃! In the next posts we will take a more detailed look on some of the CMS and how these actually work in practice. If you have questions or suggestions, don’t hesitate to contact us!