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