One thing to keep in mind is that GraphQL really supports a different use case than something like gRPC or REST. One of the places where it really shines is pr

One thing to keep in mind is that GraphQL really supports a different use case than something like gRPC or REST. One of the places where it really shines is providing a queryable API entry point to a graph of interconnected data. This makes it ideal for generally reusable APIs for consumption by a variety of clients (e.g. GitHub's GraphQL API). gRPC interfaces are typically use-case specific, and performance oriented (though GraphQL doesn't specify any sort of transport protocol, so you could always serialize GraphQL request/responses with protobufs to gain some performance over the wire), making them well suited for server-to-server communication, but not generally reusable. REST is resource (i.e. nodes in a graph) based, but doesn't necessarily do a good job of making the relationships explicit and easy to traverse (I'm sure there are good HATOAES implementations out there that address this, but I haven't seen one). Both REST and gRPC have their place, but I think GraphQL is a clear winner when you want to build a single API to service a large number of distinct clients. It really does offer a clear, easy-to-use API abstraction over where ever you might get your data from. Also, since you call out code generation specifically; GraphQL provides a strongly-typed schema that can be introspected against, and the tooling to parse queries/schemas into abstract syntax trees. A large number of tools have been built with these capabilities including a number of different code generators. I've even used a GraphQL schema to generate a matching XSD (ugh) for import into an internal business rules engine. Made integration a breeze.