After spending 3 weeks on the customization of a large-scale e-commerce application, I ultimately decided to move away from Strapi permanently.
During this process, I encountered numerous stability and scalability issues, a few of which I reported on GitHub. Additionally, the lack of basic transaction rollback capabilities was a significant limitation for my use case. Furthermore, the exception handling in the lifecycle hooks was not an effective solution and often resulted in a “400” error. Moreover, even when adding exceptions in the lifecycle hooks, the data within the component model still persisted in the database, which was the main reason for the fallback.
Furthermore, the product quality and community support were not up to par for a 31 million dollar funded solution. Strapi has many unknown issues and the future seems uncertain for developers who are looking to migrate from v3 to v4.
Even after giving Strapi another chance after two years, I remain disappointed and I must conclude that Strapi is not a suitable tool for large-scale e-commerce projects and would not recommend it for similar use cases.
Side note: Different project has different demand and for my usecase , Strapi wasn’t a good option. I suggest developer who start using Strapi should understand what the project really needs and make sure you understand the use case before choose Strapi.
For most large-scale projects, we have our users going for the enterprise edition that provides access to solution engineers. Is this the support you are referring or are you just talking about general discord conversations?
Can you provide some more information on the issues around lifecycles in general and your use-case, generally a middleware might better fit your need
As @Paul_Brats mentioned, we are open source and we provide paid support options (of which I am on the team that provides that support). This is common in the open source world, your use-case seems in line with one that would most likely be better fit by our enterprise offering to get dedicated support.
I have been using Strapi in production for years now, and even if I’m not planning on leaving I do relate with the OP.
Personally the #issue14417 has been causing me headaches for months, every 10 image uploads my app just crashes.
And just a couple hours ago I meet an entrepreneur that used Strapi for their Startup, but hasn’t migrated because he just has to re-write his entire app.
I was also very surprised by the very heavy changes made from V3 to V4. Is ok to introduce breaking changes, but V4 broke everything. If you do the same for V5 I’m not switching.
We are a small company that just want a very opinionated backend so as long as we follow the rules, things should work, and we can relay in a big community for our questions. We are very interested in Strapi Cloud.
I’m not planning on moving away from Strapi any time soon, but I can relate OP.
I was also very surprised by the very heavy changes made from V3 to V4. Is ok to introduce breaking changes, but V4 broke everything .
I feel this so much. At the time we upgraded to the then current v4 version, we had to rework way too much stuff that was not mentioned in the migration guides.
We had localization issues, the way to populate objects changed (populate deep), lifecycle hooks, we reworked fileuploads and much more things. We even had to do workarounds for some existing bugs.
Now with some workarounds and custom changes we feel like we can use strapi v4 now. But we are heavily worried to upgrade even patch and minor versions within v4, breaking our workarounds/changes that we made to finally use strapi as intended.
I hope the v5 version will not break everything again
Most of our developer team liked strapi and still like it however some of us are missing the “good old v3 days” where stuff was more straight forward and worked out of the box.
Completely understand, and while v5 will introduce breaking changes (which is largely the point of major version releases) I would absolutely not expect the same level as you saw from v3 → v4.
For us between v3/v4 we had roughly 5 or 6 years of technical debt we had to deal with to build several new features where as with the future we are hoping to do small major versions once a year and make those migrations far less painful. Instead of dealing with an extremely massive amount of debt every few years we feel it would be better to deal with it in smaller bite sized chunks once a year. While we are still defining the scope and timeline for v5, we expect to start working on it towards the end of 2023.
If you haven’t already please do sign up for the cloud waitlist as we are doing a private beta and soon a private soft-launch and pulling in batches of users every few weeks to allow for testing: Join the Strapi Cloud Waitlist
Thank you and we do greatly welcome the candor feedback and dedicated users like yourself.
Thanks for the post. I’ve asked multiple times multiple questions in the forums that never got a single answer. My major concern has always been to “keep history”.
I never started with Strapi because I felt there was not enough community.
If it supported CQRS+ES then migrations and so on would be 100% guaranteed and future compatible: You just export the book of events in version n and re-import them in version n+1.
More important: If it supported CQRS+ES, you would not lock-in Strapi: You can use strapi when bootstraping your startup and if at any point you get stuck by scalability, you can re-use the events in any newer system (even old strapi + new custom systems could co-exist going to the same event store).
I even wonder if the Strapi architects are on the “Event Sourcing” bleeding edge. I feel them stuck to the old-fashioned CRUD ideas of the last century.
@fahidmohammad Did you choose any other general-purpose platform? Or you going to custom?
PD: In regards to what @DMehaffy says I feel there’s a misunderstanding about the conception of “open source justifies the public product is below par and if you pay you’ll go the right way”. People from mautic are on the same error than Strapi. Mautic’s open source versions do not scale and have lots of breaking errors. And if you want it to seamlessly work, they say “pay”.
But this is not a justification. MariaDb, docker, gimp, the linux kernel, apache, nginx, php, kubernetes, jenkins, flutter, or elasticsearch are just a few that being Open Source are on-par or even above par for the 100% free version.
for visibility 
and we do greatly welcome the candor feedback and dedicated users like yourself.