The idea is pretty simple as for developer and for user exp.
I pretty sure not only me comfortable with that, but making frontend and backend more independent make a lot of freedom for developers.
BAD: addition work for start this application
BENEFITS:
frontend and backend has own development space and can be managed on pipelines in cloud
then easier to make migration for database and possibility to put it in separate step for building.
As you can see, all this part in packages and admin has 4 dependencies for another packages. As a developer its not looks good from design perspective. I’m not pro in Strapi and why this solution was used. It works but it has a lot of corner cases and space for discussion.
I work with Strapi in a professional environment, and on hobby basis.
And what you are saying is what we are doing, they are decoupled. Note that Strapi is a Headless CMS with an Admin UI. To be used mostly for just “Admin” work. Creating models etc, which can be done with the UI or just code.
Hosting is different as we are using an Angular application for the frontend and Strapi as the backend for multiple apps.
No, I’m not only about frontend.
As mentioned Headless CMS with Admin UI. And Admin UI started inside Strapi. The idea to make in separate processes.
I’m not sure that is use case for Strapi and migrations runs 30mins for 40k fields in DB.
The customisation of fields is really confusing when owerrite with extensions. It’s everything the same process. Frontend make frontend, backend make backend. In different packages, different processes.
Not sure there are a lot of devs faced with that and it looks like the very specific case for me and not good use case for strapi BUT it’s only idea and what think other devs in Strapi. They have more about customers and expectations.
