Two Headless CMS - Head to Head

Anders Romin
Mar 30, 2016 · 8 min read

As web sites become multi platform, the CMS systems that provide editorial content to the sites need to become multi platform too. One of the trends in this area is the headless CMS. In this post we will take a look at what a headless CMS is, how it is different from a traditional web CMS. Then we will dig deeper and compare two headless CMS products that I have worked with over the past year: Contentful CMS and Accedo Appgrid.

So what is a headless CMS then?

Imagine your traditional web CMS, like EPiServer, Polopoly or WordPress, and remove the part that actually renders html. Instead put a RESTful API in front of it and let the clients deal with the rendering themselves. The reason why this has become a suitable solution for many projects is that there are so many platforms out there and it would be nearly impossible for the CMS suppliers to keep up. Remember that 10 years ago there was just web sites and the biggest concern was if you would write it in Java, C# or PHP. Today we have many more choices just for web sites: Angular, Backbone, Rendr just to name a few. And then there is a bunch of totally different platforms where you might want to expose your service or app: iPhone, iPad, Apple TV, Android phones, Android tablets, Android TV, Samsung Smart-TV, XBox, etc. What all these platforms have in common is the capability to consume RESTful APIs with JSON. So that’s exactly what the headless CMS delivers.

What’s the point with the CMS then? Why not just put a RESTful API in front of a good NoSQL database like MongoDB? Well, we still have people that need to manage the content that is displayed on all those platforms. They are usually called editors in the CMS world. An editor’s skill is just that, to create content, and they are typically not very technical. So the CMS is primarily for them. The CMS supports their way of working and their needs: the editorial workflow. The thing with the headless CMS is that it doesn’t help the developers like the traditional ones did, but on the other hand, it doesn’t get in the way either.

Comparison between traditional and headless CMS


So let’s take a look at a headless CMS: Contentful. I first came across Contentful about a year ago. My colleagues at apegroup had built mobile apps for years, and we were looking for a good product that could help us make our apps more dynamic and editorially driven. We had custom built a small headless CMS ourselves and used in one of our projects, but it is trickier than you would imagine when you want to support an editorial workflow. So when we found Contentful we thought that it had a good potential for us!

Contentful is a cloud based software-as-a-service that is publicly available, and have a free starter plan, so it is really easy to get going. The starting point of setting up your Contentful project is to create some Content Types (I usually think of these as Templates). A Content Type defines the data model to use when creating an Entry, which is the instantiation of the Content Type. If you compare with traditional CMS, and Entry is usually called Article or Page or similar, but since we are leaving the publishing metafor behind when entering the multi platform world, a more generic term is needed, hence Entry.

Back to the Content Type, if you would compare the CMS with a SQL database, the Content Type is nearly identical to a Table definition. It has a name and a number of Fields (columns) that can contain e.g. strings, numbers, binary data or references to other Content Types (tables). So if you look at it this way, you can think of the CMS as a database where you can model any type of data that you want, but you will also automatically get an editorial GUI where the content can be managed. Another important aspect is that all the Fields in a Content Type may have validations (constraints) that control what is allowed and not, especially when you consider that the Editor is typically not a very technical person.

Once you have created a Content Type, you may also create some Entries based on the Content Type, and these Entries are then available in the REST API.

So far so good, now the next thing we need to do is to make the content available in our site/service/app. Contentful provides client SDK libraries for a number of platforms, including iOS, Android, and Javascript, so as a developer you now get to choose if you want to consume the REST API manually, or if you want to use the provided SDK. No matter which way you choose to go, it is really important to have a structure in the client that matches the Content Type structure of the CMS, and that you expect your code to be driven by the CMS data. The SDK doesn’t really help you with this, it just makes it easier to consume the data from the API.

An interesting part of Contentful is that it also provides an API for creating new content. This is a powerful feature that can be used for many things ranging from tech stuff like automation and content deployment to user features like storing user feedback to the published content, or even create your own publishing features right inside your own app.

Contentful also supports Widgets, which is a way to define your own custom field types. This could be used for many things, including integration with your backend systems or if you have very specific editing needs.

Another strong point with Contentful is that it fully supports localization, i.e. each Entry may contain translated content for the languages/markets that you define.

Now that we have a pretty clear image of the capabilities of Contentful, let’s move on to Accedo Appgrid.

Accedo Appgrid

Accedo Appgrid is both similar and different to Contentful. Accedo is a company that is explicitly targeted at the media industry and especially OTT products, i.e. video services like Netflix, HBO, Viaplay and similar. This means that Appgrid is not a publicly available product like Contentful, but it is still a cloud service. Appgrid also contains parts that are not exactly CMS related, for example client configuration, error logging and messaging. Actually the CMS part of Appgrid is brand new and I happened to be working in one of the very first projects using it, so when you google about this, there is not a lot of information out there. Still, I think the Appgrid CMS is an interesting product with a lot of potential.

At a first glance, Appgrid is very similar to Contentful. Instead of Content Types you have Entry Types (I still think of them as templates), but they are very similar and both contains Fields, and the available Field Types are roughly the same. And the resulting content objects are called Entries, just like in Contentful.

The major thing that Appgrid supports and Contentful lacks, is the built in support for content variations across platforms. This is important since we want to expose our service on many platforms with very different capabilities. Just consider the screen size difference between a 4 inch iPhone 5 and the 55+ inch Samsung Smart TV, but you may still want to present the same content on both. This is where Appgrid helps by letting you define platform specific fields in the Entry Type. For example an image for a phone might be cropped in a portrait format, while you might want to have landscape format images on bigger screens. In Appgrid you can define different validation rules for this, so that you can enforce that the editor uploads the correct image.

Another strong point of Appgrid is a more developed editorial work flow, where you can schedule publishing of content so that you can control the exact moment when your new content becomes available to your users. There is also a dedicated Review state, in case you have sensitive content that need to be reviewed by someone else before it is published.


So, which one is the winner? Let’s compare in these seven categories!


The winner of this battle is clearly Contentful. It is the more mature product, and it has a lot of nice features. But Appgrid is not bad either, I think it has a lot of potential, especially if the API’s are further developed. Which one to choose for your project obviously depends on your requirements and what type of product you are building.

Hi, I’m Anders! I work as a system architect at apegroup where I help companies plan and build complex technological eco-systems. We are a digital agency in Hornstull, Sweden. Together with we push boundaries through design of digital experiences, improving life for people. Want to know more about how we work? Read more at our website.

If you enjoyed this article, please press Recommend below!

Apegroup — Behind the Screens

Thoughts, learnings and opinions from a digital product studio in Sweden who deliver world-class design, technology and communication.

Anders Romin

Written by

I work as a solution architect for apegroup and my specialities range from backend programming and API design to system and information modeling.

Apegroup — Behind the Screens

Thoughts, learnings and opinions from a digital product studio in Sweden who deliver world-class design, technology and communication.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade