A Journey To Finding The Right CMS
What is a CMS?
A CMS (Content Management System) is software you can use to create, update and delete content for a website. For example, Apolitical uses a CMS to manage the articles we publish on our site, or groups of articles, such as our microcourses. Choosing the right CMS for your tech stack and user requirements can be a complex and arduous process. This blog post demonstrates how Apolitical chose Contentful as their CMS.
Why did Apolitical want to switch CMS?
Originally, Apolitical was a WordPress site. However, as Apolitical grew and our products evolved, it became clear that a microservices architecture was more suitable for the platform.
A microservices architecture is when you have a group of loosely-coupled services. For example, writing an API and a UI that are built separately, with little knowledge of how each other work, but are still able to communicate with each other. But, this architecture conflicts with using WordPress, which has a tightly-coupled back end and front end. Instead of abandoning WordPress completely, Apolitical has moved away from WordPress iteratively. On top of the WordPress database, we’ve built React.js front-end services connected to our Articles API, which delivers the article content you see on the site. Below is a list of reasons why we can’t maintain this technical flow.
- We were self-hosting our WordPress service, which became unwieldy and required a lot of engineering time to maintain
- The team’s expertise is predominantly Node.js, not PHP
- The Articles API is written in Rust. No one in the team specialises in this language
- As our products evolve, the WordPress interface is no longer delivering a good experience for our content team, who use it to publish their work
What is a Headless CMS and why did Apolitical choose it?
Since we have a website architecture based on microservices, we didn’t want to use the traditional CMS structure — with the back end and front end coupled together — like WordPress. Another factor we needed to consider was the size of the engineering team. We are a small team, and to build our own CMS would have taken considerable time and effort. Taking both of these factors into consideration, a headless CMS was looking like the best option.
A headless CMS is any type of content management system where the content repository is separated from the presentation layer (in our case, our React.js frontends). This allows you to structure content so that it can be reused across different platforms and channels, such as mobile, tablet and desktop devices.
How did Apolitical decide which headless CMS was right for our platform?
We evaluated 9 headless CMS. We evaluated their popularity, technical support, pricing and technical features. Below is a list of example criteria:
- NPM weekly downloads
- StackShare stats
- Open source
- Pricing tiers
- Hosting
- Content Delivery Network (CDN)
- Customisability
- Webhooks
After evaluating based on this criteria we narrowed down our search to 4 headless CMS.
The final criteria for comparison was content requirements. The users of the CMS are our content team. We needed to ensure the next CMS we chose met all their requirements, that it met the requirements of our products, and that it was an improvement on the WordPress user experience. Here are some of those requirements.
- Rich text fields for inputting the body of our content
- Media fields for uploading images and videos
- Editor/Preview modes so the user can preview their content before publishing
- Versioning so the user can compare changes of a piece of content
- Publishing workflow so the user can schedule content publishing
- Unlimited users to support our growing team
- Collaboration to allow multiple users to work on a piece of content
- SEO support to ensure that our pages continue to be visible to search engine users
As engineers experimented with the four headless CMS, they ruled out two. They found that users needed to do a lot of work to get started, and the user experience was worse than working with WordPress. This left us with two to choose from.
Strapi vs Contentful
Strapi and Contentful were our final 2 candidates. They have some fundamental differences, the most decisive of which are highlighted below.
We had a meeting where the two people who had evaluated Strapi and Contentful could demo the software to the rest of the team to share knowledge and get opinions. We walked away from the meeting with the feature lead leaning strongly towards Contentful for the reasons set out above. While we thought it met our needs better, we needed to get buy-in from any other key stakeholders.
We got two members of the content team to tell us about their experience of experimenting with Contentful. They wrote a list of advantages and areas to investigate. For example, they highlighted certain WordPress functionality they couldn’t easily see how to replicate in Contentful. We then decided that an engineer needed to de-risk and confirm that Contentful was capable of implementing these ‘areas to investigate’.
We also set up a meeting with our Lead Data Scientist to explore the risks to Apolitical’s data work if we chose Contentful. We agreed on a number of key requirements our proof-of-concept solution would have to meet to be viable. This meant the data team knew up front that they would need to change their data products when we adopted a new CMS, and that would incur a cost. But this would be true for any CMS we chose.
Once we’d done all this, we could begin work on building our new Contentful CMS and start to integrate it with one of our key front-end services. Having gone through this process and weighed up many of the options thoroughly, we can say confidently that we have chosen what we think is the right CMS for Apolitical’s platform.
Lessons Learnt
- Don’t be afraid to re-assess goals. Our original goal was to replace the Articles API . But we needed to re-assess that goal, because replacing the API without giving thought to the back end it reads from wouldn’t be efficient. While it meant it took longer for us to begin the switch-over, we were able to make headway on two goals at once (replacing WordPress and the Articles API) by adopting a new CMS.
- Spend time evaluating your options. Don’t start to build a proof of concept of the first option you like the look of. Put the time in to do the research and draw comparisons between each option, based on how well they meet your criteria (we did this in Google Sheets).
- Gather requirements early and from key stakeholders. Try not to think about just the technical and budgetary requirements. Speak to users (in this case our content team) and look at other products that may be affected by your choice, such the ones managed by our data team.
- If building the proof of concept is proving difficult or not in line with your needs, don’t be afraid to voice this early. This frees up engineering resources and ultimately helps narrow down your options.
