We have different schools of thought internally. Some prefer to tailor the backend API to the needs of the frontend, others prefer to have the backend API super generic so that changes in the frontend (say, a redesign) didn't require changing the backend. The latter is easier for backenders but harder for frontenders. It's vice versa for the former. So, the complexity stays the same, it influences which team (the frontend or the backend team) gets more complexity. However, when desiging the backend API, we always involve at least 1 frontender so that there were no "surprises".
Re:You Shouldn't Start with an SPA
by rokkitmensch on Friday February 02, 2024 @10:49PM
(#39237379)
This turns into "BFFE" (backend for frontend) in my experience, and that's not even the dumbest possible decision.
Can you adequately measure your page load performance when front-end is making many parallel requests to the back-end and not all of them are required to consider the page "loaded"?
There are countless architectural downsides associated with not just giving the front-end exactly what they need, and there has to be a very good upside for doing this. Front-end freedom is not one of them, because the freedom is minimal and mostly accidental. A good upside can be: you're building specifically an API for building your kind of web application, and you want to dogfood your own work. Otherwise, it seems an incredible amount of unnecessary contention and complexity.
That said, I don't disagree that it _kind of works_ the way you describe, but it could've worked a lot better if your API could just give the front-end exactly what they need. You could've designed it with the exact same process, and they could've worked off of mocks the same way. They just would have all the data sent to them in a much more streamlined fashion.
Disclaimer: I'm the author of https://max.engineer/server-informed-ui