The GraphQL explanation isn't correct, either. It's not about defining a contract: if you wanted to do that, you'd just throw an existing tool for enforcing sch

The GraphQL explanation isn't correct, either. It's not about defining a contract: if you wanted to do that, you'd just throw an existing tool for enforcing schemas at your JSON (Swagger as the article suggests, json-schema, Avro with JSON encoding, etc.) and be done. GraphQL has a few different advantages. Defining what data an endpoint returns on the client helps frontend teams build views without needing to A) define a new backend endpoint per view, B) cram everything for every view into one huge wasteful endpoint, or C) make a cascading set of render-blocking queries in each component such that a round-trip time of 250ms blocks the page for a whole second. It also requires defining a schema, but that's a side benefit. This is hard to explain because the problems GraphQL fixes aren't actually problems on many teams. You need a complicated and deeply nested data model and UI, loads of different screens with similar information on them, and a backend workflow where API changes cause a lot of overhead.