> you need to make a ticket for the backend work first and the front end work can only start once the backend work is finished In practice, a lot of this can b

> you need to make a ticket for the backend work first and the front end work can only start once the backend work is finished In practice, a lot of this can be done in parallel. Once the design is established, front-end can start working on the layout/UX without knowing the exact shape of supplied data. The back-end can start proposing the shape of data and populating writing SQL/other queries to populate it. The final sync will only require small adjustments. > it gives the front-end team the freedom to develop on their own timeline At the cost of backend having to support every single use case under the sun. > still you have the problem of deciding to intelligently architect your data access layer to not have massive amounts of duplicated code. All this involves, is passing the pages the data they need for their construction. The alternative is building and supporting a generic data access for infinite use cases that is hard to optimize. I see this suggested often, and I don't think it's true that the way to reduce duplication is by providing all data forever. You can provide specific entities wrapped in pages, and reuse the backend logic used for their construction. > it’s possible on the backend to just easily make restful crud for every single resource This shifts all the complexity of combining data onto the front-end, and the front-end is a lot more distant from the data storage. See the note where I describe that "Reliable communication allows for simpler interfaces"[1]. [1]: https://notes.max.engineer/reliable-communication-allows-for-simpler-interfaces https://notes.max.engineer/reliable-communication-allows-for...