4 ms·
As well as your FE team forced to wait on BE changes for new features, you've also created busywork for the BE team anytime there's a FE refactor/restructure to
by another-dave 3y ago
As well as your FE team forced to wait on BE changes for new features, you've also created busywork for the BE team anytime there's a FE refactor/restructure to boot.
- bramblerose 3y agoAn organisation that separates frontend and backend teams will naturally converge to an architecture where the collaboration between frontend and backend is minimized (i.e., a generic REST API) -- Conway's law. This doesn't mean that an actual cross-functional team that contains both frontend and backend developers can't use the proposed single-purpose API to run circles around the split team.
- another-dave 3y agoRegardless of cross-functional teams, I think having to make changes at an API level at the backend for UI changes will negate a lot of the benefit. For clarity, I don't think you need to treat your own front-end like an external consumer & think it's fine to have bespoke endpoints as needed. What I'm skeptical of is the author's suggestion that a backend endpoint brings back presentational info like "leftBoxTitle".