> This means that you bypass the API and give direct access to the data? Why have an API at all then? False dichotomy. You’re not bypassing the api. You’re ex

> This means that you bypass the API and give direct access to the data? Why have an API at all then? False dichotomy. You’re not bypassing the api. You’re exposing a richer api. Use the right terms. The purpose of exposing apis is not to limit the attributes of exposable data. Eg your definition of an object that the rest api represents May evolve over time while the api does not since they may not be in sync in the code. With graphql this is handled automatically. Of course it’s tightly coupling data storage, that is the point! The problem with using rest apis when doing this is that you can’t then change your api without breaking dependencies. Graphql recognizes that in a rapidly evolving data model, trying to model a permanence is futile. Instead it gives you and your clients tools to a) reduce expansive dependencies by querying only for data you need and b) identifying which dependencies are used and how frequently allowing you to deprecate attributes safely. This is not a tool meant for enterprises abusing rest apis as “contracts”, where every change needs to be communicated in advance yadda yadda. It’s targeted towards consumers who are ok with and actually _want_ a richer api in lieu of the stability provided by versioned apis. Good candidates for this use case include internal teams and external, non contractual apis.