I 100% agree that overfetching isn't the main problem graphql solves for me.

I'm actually spending a lot of time in rest-ish world and contract isn't the problem I'd solve with GraphQL either. For that I'd go through OpenAPI, and it's enforcement and validation. That is very viable these days, just isn't a "default" in the ecosystem.

For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

▲

Seattle3503 a day ago | parent | next [-]

> For me what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution especially in M:N client-services scenario in large systems. Having the mindset of "client describes what they need" -> "graphql server figures out how to get it" -> "domain services resolve the part" makes long term management of network of APIs much easier. And when it's combined with good observability it can become one of the biggest enablers for data access.

I've seen this this solved in REST land by using a load balancer or proxy that does path based routing. api.foo.com/bar/baz gets routed to the "bar" service.

▲

btreecat 21 hours ago | parent [-]

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

	▲	Seattle3503 17 hours ago \| parent [-]
		How do you do routing across services?

▲

hn_throwaway_99 a day ago | parent | prev [-]

Completely agree with this rationale too. GraphQL does encapsulation really, really well. The client just knows about a single API surface, but the implementation about which actual backend services are handling the (parts of each) call is completely hidden.

On a related note, this is also why I really dislike those "Hey, just expose your naked DB schemas as a GraphQL API!" tools. Like the best part about GraphQL is how it decouples your API contract from backend implementation details, and these tools come along and now you've tightly coupled all your clients to your DB schema. I think it's madness.

	▲	sandeepkd a day ago \| parent \| next [-]
		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
	▲	dfee a day ago \| parent \| prev [-]
		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.