Just read though graphql spec at https://spec.graphql.org/draft https://spec.graphql.org/draft It's very complex. Contrast it with simplicity of jsonrpc https:

Just read though graphql spec at https://spec.graphql.org/draft https://spec.graphql.org/draft It's very complex. Contrast it with simplicity of jsonrpc https://www.jsonrpc.org/specification https://www.jsonrpc.org/specification It focuses a lot of attention on result part, not so much on query input part. Contrast it with MongoDB-style querying which can be mapped to SQL as well allowing client to construct arbitrary where clauses. Trivial in jsonrpc, not possible in graphql. Input object type doesn't allow union types, which is quite bad. It means MongoDB style queries can't be constructed - query input is rigid. Jsonrpc allows it. There is no concept of parametric polymorphism. Jsonrpc on the other hand allows you to take advantage of type system in your programming language. Optionality at input position is odd: - nullable types are implicitly optional - non-nullable types are implicitly required This doesn't make sense. There are apis where you'd want to: - have parameter that is required, however may be null - optional parameter that cannot be null - is not provided (ignore) or is provided (use) This creates odd api where you need to allow querying by field with null value even though it's invalid (ie. optional query parameter for non nullable property). I also can see why people criticize it for encouraging over-fetching and creating n+1 problems on the backend.