>Are you proposing just to add new field to a JSON response, even though they are not needed?
That is exactly what OP is proposing and it makes total sense. More data != bad. Just ignore if you don't need it. For 99.999% of cases the bandwidth of extra data is entirely negligible.
For business cases you just want to get things done. If the server has added more data, which is obviously relevant in some regard, you can see it and might want to use it etc. With GraphQL you are completely stuck without SPECIFICALLY requesting it. That means every client needs to know about the new data and specifically request it. In theory that might sound like it makes sense, but in practice this is virtually never the case.
Give me all the data and I'll use what makes sense.
This sounds like a facetiously-simple answer, but it's entirely earnest. If the data properly belongs as a property of the object, return it in the object's representation. If the "data" is actually an ID of a related object, return that id (or, better yet, the URL at which to find information about that object) as a link.
Domain-Driven Design is much over-hyped, but on this they were right on the money.
("But then you have to make multiple requests to gather information which crosses the boundaries of many objects". Yes. And? Beyond a reasonable point, latency is nowhere near as important as many developers like to think it is, especially when compared with a simple and straightforward API - and if this is one of those rare cases that is on the critical path, you _can_ add a dedicated getFooWithAdditionalBars endpoint to your REST API)
Even in REST, I’m sure you don’t use every field from every request? In fact, such tight coupling between FE and BE in REST is strongly advised against. And “wasted fields”
was never a problem graphql was trying to solve.
Are you proposing just to add new field to a JSON response, even though they are not needed?