3 ms·
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 dif
by etherfirma 10mo ago
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
- rbalicki 10mo agoI 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/ 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...)
- devmor 10mo ago> 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.
- rbalicki 10mo agoYou may be interested in checking out https://www.youtube.com/watch?v=lhVGdErZuN4 https://www.youtube.com/watch?v=lhVGdErZuN4, where I talk about the benefits of Relay. This isn't (currently) possible without GraphQL, so it's a pretty compelling case for GraphQL. But yeah, IMO, GraphQL doesn't justify itself unless you're using a client like Relay, with data masking and fragment colocation.
- devmor 10mo agoThat is an interesting talk, thank you!