Our frontend team needs to show the whole thing every time (as the user sees and edits full resources in most cases), which means they MUST keep a full query representing the entire resource, and when we add stuff in the backend, they must also add those things in the frontend (as they cannot generate UI for new things in most occasions). GraphQL was really a mistake for us.
>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.
No, that's an important facet of compatibility. If a change is purely additive, existing clients will keep working, something the industry has basically forgotten all about, it seems.
I think I have to agree with this correction in general, but don’t take one commenter for a whole industry please. I’m not even remotely representative of it.
depends. i'd be writing the client such that it just lists all the fields, and then add special handling for the fields that need it. when the backend adds new fields, they will just show up and i just need to fix the formatting. with graphql i'd have to ask for those new fields, and thus make changes in two places. and in addition the backend team has to tell the frontend team about the new fields (instead of letting the api speak for itself), making it easier to accidentally skip a field.
(Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory.
It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI
