I don't agree with the author on most of this. GraphQL is far better than REST in almost every way and I disagree that the server side resolvers are somehow difficult to write. In a true enterprise setting, the federation capabilities are fantastic.

There are plenty of things to dislike about GraphQL that he doesn't touch on, like: * lack of input type polymorphism * lack of support for map types * lack of support for recursive data structures (e.g., BlogComments) * terrible fragment syntax

I would encourage you to write an educated person's critique of GraphQL, because OP's article + https://bessey.dev/blog/2024/05/24/why-im-over-graphql/ etc. suck up all of the oxygen, and no one hears about the genuine issues like that.

(And don't forget lack of generics, no support for interfaces with no fields, lack of closed unions/interfaces, the absolutely silly distinction between unions and interfaces, the fact that the SDL and operation language are two completely different things...)

> GraphQL is far better than REST in almost every way

I hear this so often, but never do I hear more than one or one and a half ways that it is better. No one seems capable of explaining how it's "better in almost every way" without diverging to very specific examples with cutout problems.