You're right. GraphQL definitely seems like that. There are a few nuances though: 1. GraphQL is like SOAP for JSON. JSON is important to lot of developers toda

You're right. GraphQL definitely seems like that. There are a few nuances though: 1. GraphQL is like SOAP for JSON. JSON is important to lot of developers today, especially the frontend/javascript ecosystem 2. GraphQL also helps developers think of data as related entities in a way that fits JSON. Nested objects and arrays essentially, but not ad-hoc. Hence a "schema" of your "graph" that describes the API. 3. GraphQL has a construct called fragments that makes it easy to declare data-dependencies at a UI component level that are then automatically composed together into a single query by graphql client tooling (at build time ideally). This can be done with JSON as well, but the ergonomics with GraphQL are nicer. None of these are truly "new" ideas perhaps. But I think all of it coming together is new. That said, the complexity of building and maintaining a GraphQL server is definitely non-trivial in the real world. For example, health-check tools often rely on HTTP status codes in responses to check service and API health. This doesn't work well with GraphQL because GraphQL supports partial errors and responses, and the error itself is embedded inside the response. This means analysis the response is necessary. This means that the privilege required for the health-check tooling is greater. Responses should not be logged or analysed by third party services without taking a lot of explicit care.