So then, are you building your backend API directly to meet the needs of your front-end? Or are you trying to keep it generic for all needs, but also serve the

So then, are you building your backend API directly to meet the needs of your front-end? Or are you trying to keep it generic for all needs, but also serve the front-end? Are you telling the front-end team to download multiple resources from multiple endpoints when they need to render one thing? Do you have real life other consumers of your API? Are you juggling their requirements vs internal requirements? Is your backend team telling the frontend "it's not a good API design if we give you exactly what you need, so instead please pull these multiple resources?" 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 https://max.engineer/server-informed-ui