Jon Palmisciano

My experience with Strapi

A friend recently hired me to help build a small online store for him. He had three main requirements:

  • the store to be up and running ASAP;
  • it had to be easy for him to manage; and
  • it had to be built with JavaScript.

Typically I would have chosen Express or Koa, I wanted to see if there were any frameworks that would better satisfy the first requirement, which led me to Strapi, the “fully customizable” headless CMS.

Strapi provides a lot of functionality out of the box, meaning more time could be spent working on business logic. Furthermore, their claims regarding customizability are generally true. I had never used Strapi before, but after a good test-run and seeing positive online reviews, I decided I would use it.

Disclaimer: Choosing a framework based on first impressions is obviously bad. This project was for a close friend of mine, who understood the implications of my inexperience with the framework prior to starting the project. I wouldn’t advocate using technology you aren’t comfortable with when doing freelance work under normal circumstances.

Where Strapi excels

A brand new Strapi application comes pre-configured with a database, users and permissions system, an admin panel, and more. Create a database model from the admin panel, and API endpoints for it will be automatically generated for you. If you want to hide a field from API responses or restrict access to certain API routes, there’s a checkbox for that.

If you need to add some custom business logic, you can override the default controller methods. Strapi also makes it easy to access your database, send emails, etc. from inside your custom controllers. There is a lot that Strapi does well, but it isn’t perfect.

Where Strapi falls short

Having lots of functionality out of the box does save time, but shortcuts of this nature are often compromises in disguise. In no particular order, my complaints about Strapi are as follows:

  • Many questionable settings are stored in the database. When you first deploy Strapi to production, you must manually configure all of your roles, permissions, email templates, etc. again. Storing things like roles and permissions in files would make much more sense, also allowing them to be tracked in version control.

  • Strapi does not support database migrations. The schema of your database is automatically modified when you create or update a model, but not always elegantly. Database migrations would allow for easier and more reliable setup of new instances.

  • Strapi eagerly populates model relationships by default in API responses, and the (documented-only-though-GitHub-issues) way of disabling this behavior no longer works. API requests will often suffer increased latency because of this.

  • Changing the ACL policy of uploaded content (at least for S3) requires forking Strapi’s S3 upload provider. Furthermore, I tried exporting additional methods from the provider (functionality to generate signed URLs), but Strapi refused to make them available to my program.

  • The raw body of a API request is unable to be accessed, which makes validating the signature of requests from Stripe webhooks, for example, impossible. This has been solved! You can read the GitHub issue here.


While Strapi is a great platform for creating simple APIs, I wouldn’t recommend it for larger-scale applications. It should be noted that at the time of writing, Strapi only exited beta about a month ago. The platform still has room to grow, and my use cases may not have been exactly what they had envisioned. For right now, I wouldn’t build any large-scale applications in it, but keep your eye out for it in the future.