8 ms·
Don't think I could disagree any harder. Requirements change. Business needs change. You want your FE to be able to evolve independently without having to wait
by Spiwux 3y ago
Don't think I could disagree any harder. Requirements change. Business needs change. You want your FE to be able to evolve independently without having to wait for the BE to implement the precise logic you need.
- another-dave 3y agoAs 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".