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.

Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.

If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?

Indeed, this is what graphQL solves.

Are you proposing just to add new field to a JSON response, even though they are not needed?

>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.

What decides what data to include?

Or are you just sending all data the client cloud possibly see over?

The data related to the object being returned.

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)

GraphQL "solves" the ability to ignore an unneeded field in a response? Revolutionary.

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.

We are in complete agreement - I was criticizing the implication that it was impossible to ignore fields in a REST response.

Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.

In OOP, the equivalent - getting an object of some more specific type than the one you asked for at API level - happens all the time.

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.

I'm not, I'm using my decade of experience and nascent alcoholism.

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.

One problem is performance.

(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

it sounds like they are just dumping every field to somehow show the user without any validation/specific rendering logic for each field

We do something similar and it's because GQL at my company is really pointless. I think someone at some point someone also got on the hype train not realizing that we do not really need to have hyper specific queries we can write on the fly. I can't think of a single instance where someone proposed a feature and we all went well, we can combine these 3 things we already have into a new query and the backend has no work to do. The backend always ends up building out more into graph and have been doing so for at least 6 years now. There have been a handful of cases where we did combine something old with something new but given the extra complexity on the client and backend I'm not sure it was worth it over making 2 separate calls.

This isn't actually that terrible since these fields are cached by a client-side library like Apollo. If the query has already been made elsewhere then it won't be doing any extra work

The only downside is if one of those unused fields changes due to a mutation then all components using that field will rerender (ofc I'm assuming React here). Again, not the biggest concern if you've got your memoization set up correctly

You missed the actual downside of this only works if there is no mutations in the background from other clients/processes making your cache stale.

you can poll or subscribe within GQL. The same solutions you'd use with a rest-based api

The difference is that the client came up with its own data access patterns instead of having to rely on the server to design the exact endpoints that it needs.

Overfetching or not, that's a rather big difference.

Sure, but just how often is the client the one who defines what data it needs without the designer being able to create obvious endpoints?

Surely there are some good use cases.. just so few and far between. No one should be using GraphQL unless absolutely necessary.

Yup, we saw the same thing. Everyone wants RPC. That's it. We keep inventing crazy complicated patterns on top of RPC that serve mostly as good fodder to yell about in meetings, when `POST /list_users` and `POST /create_user` work great.

Sounds like an issue with your team rather than graphql