I actually wrote on Twitter about exactly this post: https://twitter.com/jensneuse_de/status/1634678574274813952?t=zlNACJFz7XI3pZSZ7kGFKw&s=19 https://twitter.c

I actually wrote on Twitter about exactly this post: https://twitter.com/jensneuse_de/status/1634678574274813952?t=zlNACJFz7XI3pZSZ7kGFKw&s=19 https://twitter.com/jensneuse_de/status/1634678574274813952?... The tldr is that most comparisons of GraphQL, REST tRPC and whatnot don't mention Fragments and Relay because a lot of developers don't understand the purpose and value of Fragments. Per-component data dependencies, data masking, persisted operations just to name a few. Not every application needs these features, which is fine, but if you don't leverage GraphQL to the fullest, why add the complexity and not just go with something simpler like tRPC. On the other hand, there are backend for frontend frameworks like WunderGraph (https://WunderGraph.com https://WunderGraph.com) that take the advantage of GraphQL, but combine it with the simplicity of RPC. (Shameless plug, I'm the founder) That said, I think a lot of people overuse or misuse GraphQL in situations where it doesn't really add much value. E.g. when exposing an API to third parties, our API is probably consumed by a backend. What really is the benefit of using GraphQL in this case? Wouldn't an OpenAPI/REST API be much easier to adopt for your users? GraphQL really shines when used as a first party API from the frontend, with a client like Relay that embraces Fragments. Everything else to me is hype driven development. my2c