GQL can abstract auth layers for external services, the user only has to auth with your service. The user only has to keep track of your single GQL url path instead of remembering “GET /users, PUT /posts, etc”. You’d probably have a premade GQL playground setup at the single URL too. If you forget the query options, do an introspection query, which most interactive GQL clients do in the background for you. It also makes caching/memos really easy, as you can memoize the GQL layer based on user query instead of implementing it for each upstream resource. Same deal with rate limiting. Also being able to ask for arbitrary number of resources by just making more named queries in a single request can be useful.
Having the .gql file be THE source of truth and typing for your schema is really nice. Most other setups I've seen like OpenAPI are usually disconnected from your actual API code, where it’s technically possible to diverge from your stated schema.
However I think we've seen a lot of 'GraphQL as the default paradigm from the get-go', which I think is a trap and has caused a fair bit of pain for all the small startups out there that were sold on this.
If a framework requires you to be just as, if not more competent in its niches to achieve the same end you could've achieved without it, I think that makes it bad.
That's like if an HTTP framework could only be effective at the protocol level with a team competent in HTTP. The whole point of a framework is abstraction.
I have never once seen how GraphQL (the language) provides any sort of abstraction that the general framework itself doesn't, and the little abstraction GraphQL the framework does provide you can mostly sum up by just generating an OpenAPI over a set of schemas, with a whole host of benefits and few trade offs (on the implementation side, which is where your 10x devs usually live anyways).
It's weird. It's like the main benefit of GraphQL is that there are groups of developers who understand it, but the biggest drawback is that it is needlessly complex, which again, seems to indicate GraphQL is bad. It's an abstraction that creates needless complexity (that you necessarily can't reverse because it's apart of the spec..)
I essentially only do that for mutations, and they are no more complex than writing POST handlers.
Essentially all the rest is schema-first and it's _so_ quick and simple.
If you do need them, as you said it's going to be complex either way.