[robbyiq999]

GrahpQL was something that came up heavily in Front-End job ads and maybe even mentioned during my experience interviewing around 2017-2020 I was once even turned down for not having enough "GraphQL Experience" - Whatever that was. This was during a particularly painful 6 month rut for me - job search wise. It's absolutely infuriating that the tide has now changed. GraphQL doesn't matter. Did it ever? What was the point?

[rpgwaiter]

I find it really useful when your API accesses many different data sources, especially if they aren’t ones you control. You can make requests out only if you need to based on the query fields. It’s a great layer of glue for other APIs. If those other APIs are also GQL the process is very easy on your end.

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.

[treve]

Web development goes through annoying hype cycles. GraphQL has great use-cases but it was overvalued. Unfortunately even if you recognize it you can't always avoid it if you want to be competitive in the market. Cynicism can be a trap with this stuff because it may just make you less hireable.

[ecjhdnc2025]

I personally think GraphQL delivered on quite a lot of its hype, and I have become a bit more forgiving of web dev hype cycles in the light of crypto, NFT and generative-BS hype cycles...

[treve]

In my opinion the GraphQL 'wake up call' (if we can call it that) has less to do with its intrinsic value. With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad.

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.

[megadal]

> With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad.

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

[ecjhdnc2025]

I think it's needlessly complex if you have to write resolvers by hand.

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.

https://lighthouse-php.com

[megadal]

If you don't need to write resolvers by hand, from experience I can tell you writing an OpenAPI over an ORM/ODM is trivial and will accomplish the same end. It's schema-first and quick and simple (it's as simple as defining the schema in your ORM library, your generator will handle the rest)

If you do need them, as you said it's going to be complex either way.