Hacker News new | ask | show | jobs
by treve 701 days ago
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.
1 comments
megadal 701 days ago
> 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..)

link
ecjhdnc2025 701 days ago
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

link
megadal 701 days ago
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.

link