Thank you for sharing your feedback and concerns about Strapi and our move to Strapi 5. I understand the frustrations surrounding breaking changes during major migrations, especially when they may impact your project’s backend or frontend.
We learned from the Strpai v3 to v4 migration and are working hard to simplify this process. With our improved migration tool and backward compatibility API response flag, you can return your Strapi 5 data in the Strapi 4 responses format. That way, you can migrate your project incrementally instead of simultaneously focusing on both your front and backend.
However, we also want to focus on making Strapi 5 the best headless CMS possible. With new features come new requirements, which involve breaking changes.
We aim to mitigate this as much as possible, but avoiding breaking changes altogether is impossible.
In regards to entityService, new API response, and Lifecycles:
Technically, the entityService is still there (it doesn’t work exactly like it used to, but it is very close). We did add some backward compatibility options (the v4 header for REST and the GraphQL v4 format option).
Lifecycles still exist, but docSrv middlewares are new. But you bring up many good points, and we need to be more transparent about why we are making specific internal changes.
We need to provide more context. Here are some questions that have come up:
- Why did we need the documents system?
- Why did we need to change the response format?
- Why did lifecycles become less valuable?
- Why is there no localization field anymore?
- Why did we remove the helper plugin?
- Why was there so many changes to the design system?
- Why can’t they modify the admin panel anymore?
To our team internally, these questions may be clear and understood. Still, we need to do a better job of sharing these answers with the community.
We do that during our Community Calls when folks ask questions.
We need to dedicate more content around our product & engineering decisions in why and how we made them.
So we can provide more context around the change rather than say, hey, we did this.
Moving forward, we will continue to strive for more visibility around support, significant releases, and development from product and engineering perspectives.
In the past, most of our content has focused on using Strapi and introducing new features rather than on the necessary changes we were making from product and engineering perspectives, the benefits they bring, and how they align with our long-term vision.
This could help bridge the gap between our engineering decisions and user expectations.
Working at Strapi, I learned one thing: Everyone on our team is committed to making Strapi better.
Our goal is to find a balance that allows us to innovate while maintaining the trust and confidence of our community.
Thank you for sharing your thoughts and providing feedback. It means a lot to us. I know we are not perfect, but we believe in Strapi and want to see it continue to grow and improve.
Thank you to Pierre, Derrick, Alex, and many others for the internal discussion surrounding this feedback.
Feel free to add any additional comments or questions. I will continue to pass along your feedback.