For the past few months I have been using a technology called Strapi on a medium-sized project to save a whole lot of time. If you want to skip over the “What is…” sections, my experience, and my personal pros & cons, there is a TL;DR at the end.

A silly snippet of some Strapi code — specifically, a create controller

---

What is Strapi?

If you are not familiar with it, Strapi is a JavaScript-based open source headless CMS (Content Management System). It is a powerful system that handles a lot of the monotonous tasks that an application developer may go though, while providing a way for non-developers to create, edit, and manage content.

“Headless” in this context means that you can use any front-end technology stack you like. This differs from something like traditional WordPress, where you are tied to the front-end stack (PHP) of that framework.

There are a couple of other platforms that provide a very similar feature set to Strapi, maybe most notably Contentful. I think one of the main differences being, Strapi is open source and free — assuming you self-host — whereas Contentful is closed source and costly.

Why would I use Strapi?

I think some of Strapi’s most notable features and attributes are

• Modern content management interface
• Support for any data model
• Auto-generated REST & GraphQL endpoints
• Plugin system to add things like email, user authentication & authorization, media management, and API documentation
• The ability to be consumed by any front-end

Personally, I’ve been using a single Strapi deployment as a back-end for both a customer facing React Native mobile application, as well as a React back-end management application.

My Experience with Strapi

Getting started with Strapi was extremely easy, it took me all of 5 minutes to have something up and running. My experience in the first few weeks was very similar to those first 5 minutes.

As we discovered business requirements, I could update the content model and in a few minutes have CRUD operations over both REST and GraphQL for those new entities. Compared to the monotonous task of writing the migrations, creating services and controllers, and hooking up the public API for every single entity, this was a godsend.

Once the project had progressed past a certain point, I began focusing on some of the more complicated or challenging business requirements. For example, supporting mobile push notifications in a variety of situations. Many of these tasks were quite straightforward, but as I started to stretch the boundaries of what Strapi was designed for, things became progressively more difficult.

I do not think that this is necessarily surprising. Many platforms, technologies, architectures, paradigms, and other software things follow this pattern. After all, there is the extremely popular phrase: “Make easy things easy, and the hard things possible” that may, in some sense, describe this. Many of these issues I experienced, however, are areas in which I think Strapi can grow.

#strapi #cms #open-source-software #javascript #headless-cms