Comment by hn_throwaway_99

Doesn't even need to be a proxy, you can lay out your controller and endpoints like this just fine in most modern frameworks

I have used, implemented graphQL in two large scale companies across multiple (~xx) services. There are similarities in how it unfolds, however I have not seen any real world problem being solved with this so far

1. The main argument to introduce has always been the appropriate data fetching for the clients where clients can describe exactly whats required

2. Ability to define schema is touted as an advantage, managing the schema becomes a nightmare.( Btw the schema already exits at the persistence layer if that was required, schema changes and schema migration are already challenging, you just happen to replicate the challenge in one additional layer with graphQL)

3. You go big and you get into graphQL servers calling into other graphQL servers and thats when things become really interesting. People do not realize/remember/care the source of the data, you have name collisions, you get into namespaces

4. You started on the pretext of optimizing the query and now you have this layer that your client works with, the natural flow is to implement mutations with GraphQL.

5. Things are downhill from this point, with distributed services you had already lost on transactionality, graphQL mutations just add to it. You get into circular references cause underlying services are just calling other services via graphQL to get the data you asked for with graphQL query

6. The worst, you do not want to have too many small schema objects so now you have this one big schema that gets you everything from multiple REST API end points and clients are back to where they started from. Pick what you need to display on the screen.

7. Open up the network tab of any *enterprise application which uses graphQL and it would be easy to see how much non-usable data is fetched via graphQL for displaying simplistic pages

There is nothing wrong about graphQL, pretty much applies to all the tools. Comes down to how you use it, how good you are at understanding the trade-offs. Treating anything like a silver bullet is going to lead in the same direction. Pretty much all engineers who operated at the application scale is aware of it, unfortunately they just stay quiet

I agree as well. This may be the only thing GraphQL excels at. Dataloader implementations give this superpowers.

OpenAPI, Thrift and protobuf/gRPC are all far better schema languages. For example: the separation of input types and object types.

Agree with the other comments about writing OpenAPI by hand. It’s really not that bad at all, and most certainly not “verbose to the point of absurdity.”

Moreover, system boundaries are the best places to invest in being explicit. OpenAPI specs really don’t have that much overhead (especially if you make use of YAML anchors), and are (usually) suitably descriptive to describe the boundary.

In any case, starting with a declarative contract/IDL and doing something like codegen is a great way to go.

I write all of my openapi specs by hand. It's not hard.

I use https://typespec.io to generate openapi, writing openapi yaml quickly became horrible past a few apis.

OpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.

Thanks for mentioning this. I always find it unsettling when I've researched solutions for something and only find a better option from a random HN comment.

Site: https://kubb.dev/

Openapi is older than graphql.

But the point is that that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql over something else.

Is dealing with GQL easier than implementing a BFF? There may be cases where that is true, but it is not always true.

> Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all

Right, so if you take away the resolver composition (this is graph composition and not route federation), you can do the same things with a similar amount of effort in REST. This is no longer a GraphQL vs REST conversation, it's an acknowledgement that if you don't want any of the benefits you won't get any of the benefits.

> If a server gets inputs it doesn't recognize

If you just slap in Zod, the server will drop the extra inputs. If you hate Zod, it's not hard to design a similar thing.

> or if client and server disagree that a field is optional or not

Doesn't GQL have the concept of required vs optional fields too? IIUC it's the same problem. You just have to be very diligent about this, not really a way around it. Protobufs went as far as to remove 'required' out of the spec because this was such a common problem. Just don't make things required, ever :-)

Pruning the response would help validate your response schema is correct and that is delivering what was promised.

But you're right, if you have version skew and the client is expecting something else then it's not much help.

You could do it client-side so that if the server adds an optional field the client would immediately prune it off. If it removes a field, it could fill it with a default. At a certain point too much skew will still break something, but that's probably what you want anyway.

You're misunderstanding. In GraphQL, the server prunes the response object. That is, the resolver method can return a "fat" object, but only the object pruned down to just the requested fields is returned over the wire.

It is an important security benefit, because one common attack vector is to see if you can trick a server method into returning additional privileged data (like detailed error responses).

Sorry, I made a typo:

Request can be tampered with so there's *NO additional security from GraphQL protocol.