Strapi is a CMS. It’s not really meant to be used as a backend for an SPA or web app.
You will end up with a complicated infrastucture if you go that route instead of using a traditional REST API for a backend.
I mean, possibly not. If you’re dead-set on using the JAMstack for your app then Strapi + React/Vue/Whatever is a good bet.
I have built a couple complex apps with it. Just because you can doesn’t mean you should.
With Node.js / Express, You can prototype something very quickly.
Thank you for your opinion 
Just wanted to clarify that not all “CMS” are created equal, Strapi is specifically a Headless CMS, so it’s specifically designed as a backend for just about anything (not just JAMStack, but web apps, games, desktop applications, ect).
Here is a rough breakdown of different types of CMS:
Interesting feedback. But I strongly disagree. Just my two cents: Strapi is not “just” a CMS. It’s a valid foundation for all kinds of use cases, which includes serving as a backend for SPA/WebApps.
For me Strapi is so much more than just Node.js and Express. That is comparing apples and oranges.
I am happily using Strapi for several projects as the application back office, including:
For me strapi is not an overcomplicated infrastructure. I can setup a new instance in 15min on Digital Ocean and Mongo Atlas. For example. Then I have a admin backoffice with a clean UI, REST/GraphQL support, data modeling with components, relations and even dynamic zones, and a robust authentication system.
Sure if you don’t need all this then vanilla nodejs+express is a valid choice, too. But I don’t want to miss all the Strapi goodness that increases productivity (and stability) a lot for me…
Sure strapi is still very young and I have a long list of feature requests, but that is another story ;D
Again. This is just my personal opinion. And it should always be: Chose the right tool for the right job!
Do you have any suggestions about newsletter management. Request and confirmation to subscription.
Sure, we are using strapi for CRM app, performance very low. Response times is too long if your data is big. We are planning switch to nodejs express.
Are you still having performance issues with Strapi?Which version of Strapi are you using?
Hey there, great post! As someone who’s new to this forum but not to the tech industry, I appreciate hearing different perspectives on the best way to build web apps. Speaking of CMS systems, have you ever heard of online crm system Planfix? I’ve been using it for managing customer relationships for more than two years, and it perfectly fits my needs. Have you had any experience with it? Let’s keep this thread updated with our software recs, folks. Waiting for your replies!
You should not compare something oldfashioned like planfix with Strapi.
We use Strapi because we haven’t (had) much experience in NodeJS. For us it’s better to start with a architecture that Strapi gave us und start making our progression in this “limited” freedom. After multiple years (since early 2020) using Strapi we consider Strapi v3 as the better Strapi (in comparison to v4) however we hope for improvements in v5 (to be more like v3 was). But after all this time we no longer fear building our own NodeJS / Express if customer demands and Strapi limitations require us to do so.
Just out of curiosity what makes v4 worse compared to v3? Also what are the limitations of strapi that are the biggest issues for you?
I would not start blaming strapi, I have used it for major projects that required flexibility and scalability. We used it in a small team and it worked great, all the performance issues were mostly data related, not everyone seems to grasp proper data design. You will face the same issues on node.js and express, anyways strapi uses koa behind so if its slow here and it will be slow there 
.
Not the person you asked, but there’s several things that were better on v3.
The biggest being the query syntax; for example a very common operation (selecting objects by relation) that was straightforward (users?organization=3) becomes tedious in v4 (users?filters[organization][id][$eq]=3) and even more tedious when you want to populate this or that.
The relationship rework is very annoying; v3 respected the battle-tested relational database standards f.e 1:1 and 1:N being foreign key integers on the relevant tables. v4 diverges from that with its “everybody is N:N” approach. I won’t list all the implications of this but there are many.
The “pagination by default” change was also extremely annoying for us, since our client apps didn’t implement pagination (for reasons that are our own). We did successfully work around this, but the change was very opinionated and unexpected (and for us at least, unwanted).
There are others annoyances. But I’m aware there are also plenty of things to gain in using v4 (including for the specific changes I mentioned - it’s true the new query engine is generally more performant and allows more things), and I’m sure each change has been discussed and is theoretically justifiable for given usecases.
It’s just that we (and I) enjoyed Strapi as a way to have a standard file architecture along the backoffice and user-permissions plugin, things that doesn’t come by default with bare node.js/express but are good foundations for a number of projects. The post of simonwidjaja resonates a lot with me as I too have built a number of projects around a strapi (v3) backend.
Strapi becoming more and more opinionated is not a good thing for the way I used it until now, but I’m sure plenty other people are benefiting from the changes, so hey. As he said, as long as we choose the right tool for the right job, everything should be alright.
