Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Webseite zu analysieren. Außerdem geben wir Informationen zu Ihrer Verwendung unserer Webseite an unsere Partner für soziale Medien, Webung und Analysen weiter. Unsere Partner führen diese Informationen möglicherweise mit weiteren Daten zusammen, die Sie ihnen bereitgestellt haben oder die sie im Rahmen Ihrer Nutzung der Dienste gesammelt haben. Sie akzeptieren unsere Cookies, wenn sie "Cookies zulassen" klicken und damit fortfahren diese Webseite zu nutzen.

Cookies zulassen Datenschutzerklärung

Experiences with the Strapi CMS

All I want from a CMS is that it is affordable, easy to integrate and intuitively to use. I know, it is a lot to ask for. But a CMS is also an essential part of many of our client projects. So when we added Node in addition to Rails to our development stack, we inevitably came to a point where we had to decide what JavaScript-based CMS solution we wanted to work with in the future. One option we explored was Strapi.


Strapi is more than just a CMS. It is a fully functional Koa server that works as an ORM and even provides an API. It currently supports MongoDB, Postgres and MySQL.

For testing purpose we ran Strapi CMS as a secondary server alongside our Express server while both had access to the same Postgres database. At first glance, Strapi CMS was promising. Nice looking UI, easy to setup, works with a selection of the most popular databases.

In practice, it was not.

To be fair, some of the problems we encountered in the beginning have been fixed in the meantime and that at least speaks for the constant development and maintenance of the project. However, during hour-long, frustrating debugging sessions I had to dug deep into the Strapi code to identify the cause of white screens and infinite loading in the CMS UI. And I was not happy with what I found. 

One of the main design choices that created almost all of the problems we encountered was to create the CMS UI from data in a local store. Not from the database or the JSON file that you have to create to describe the model, its fields and relations. From the local store. A store, that cannot be pushed with git or manipulated manually without great effort. 

I think this design choice is very unfortunate and causes many problems. The Strapi CMS team has been trying to fix those but instead of curing the disease and not use the local store, they just treat the symptoms by making some changes to how their code interacts with the store.  I'm going to proceed by outlining the problems and obstacles I encountered during development.

Deleting is not deleting

A problem that occurred during the early times of development was, that creating e.g. a field with the name comment of type Integer, then deleting it and then creating it again, this time with the type String, broke the UI. The reason was that the store has not been updated when the field was deleted. So the type stored in the store was still Integer, whereas the database had saved it as a String.

You cannot edit the models in the code

Strapi's solution to that problem is that you should not edit the models in their model JSON files. You should instead use their plugin, the Content Type Builder and edit the models through the UI. Alright, I can do that. But it feels weird and a little bit like a cheap solution because it does not really solve the actual cause of the problem.

Impossible to use in production

While working on a real live project, there comes a time where you have to deploy your code to a production server. And there Strapi has a big problem: when you push your code to Heroku, you do not push the content of your local store. So here you get exactly the same problem as mentioned before: the store is not updated correctly which leads to a discrepancy between the actual database and the store.

Copy the core_store table

A recent solution to this problem is, to create the store from a table. This table is called core_store. So what you have to do is copy the contents of of that table from your local database to the table in the production database. Well, that works, but why is it necessary? Why can I not just push the model files and the UI is created from those? All the information is there. Why do I have make this extra effort for it to work?

As mind-boggling as it is, it's an inconvenience I could live with if the CMS would otherwise work fine. Which is unfortunately not the case.

Collaboration on the CMS does not work

We work with multiple developers on a project and even though everyone has a main responsibility, we can all make changes to frontend or backend, if needed. So in the best case the frontend developer can make a minor change to the CMS without having to ask the backend developer to do that for them. Just create a new branch, make a pull request and merge it after the review. While it is easy to merge code, the same cannot be said for merging database table contents. Because that is what I would have to do with the core_store table entry in order to get the correct version of the store in my main branch. It just feels so wrong to do it likes this.

Other instabilities - and those are just the problems caused by the store design. We encountered other problems and when we noticed that the Strapi server crashed unceremoniously every time someone opened the edit view of an entry for longer than a minute, we were at a point were it was just not reasonable anymore to continue with Strapi CMS.

As nice as it looked in the beginning, it turned out unusable for us in a production setting. Yet Strapi CMS is still in its alpha phase and the customizable UI is something we would readily present to a customer. It is easy to use and provides many desired features like a WYSIWYG editor and file upload (which was easy to connect to AWS S3). Seeing that the Strapi CMS Team knows about the issues that are created by the current data store design, there might be hope that they will find a clean solution in the future. 

Then we would happily give Strapi CMS another try.

Update 27.10.2019

This article describes our problems in January 2019. The team of strapi was quite busy this year and they have done good improvements. Lookup their public product board to see what's coming and they are very helpful in their slack channel.

Teile diesen Artikel:

zauberware logo