2 ms·

But Graphql doesn’t enable more functionality than the API already gives you. You don’t get more access to data just because you use graphql? And a team that gi

by he0001 7y ago

But Graphql doesn’t enable more functionality than the API already gives you. You don’t get more access to data just because you use graphql? And a team that gives direct access to their data is in very much deep trouble already. I really don’t get what you are getting with this.

pm90 7y ago
> You don’t get more access to data just because you use graphql? The data you expose via apis is often one “view” of the actual rich data store you own. If a dependent team wants more data than your rest api provides, it is blocked on you adding that data to your api. If you instead provide a way to query your data store, the dependent team isn’t blocked on you.
- he0001 7y ago
  >If you instead provide a way to query your data store, the dependent team isn’t blocked on you. This means that you bypass the API and give direct access to the data? Why have an API at all then? Don’t you think that this mean you tightly couple the data storage with the client?
  - pm90 7y ago
    > 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.

by he0001 7y ago

pm90 7y ago

> You don’t get more access to data just because you use graphql? The data you expose via apis is often one “view” of the actual rich data store you own. If a dependent team wants more data than your rest api provides, it is blocked on you adding that data to your api. If you instead provide a way to query your data store, the dependent team isn’t blocked on you.

he0001 7y ago
>If you instead provide a way to query your data store, the dependent team isn’t blocked on you. This means that you bypass the API and give direct access to the data? Why have an API at all then? Don’t you think that this mean you tightly couple the data storage with the client?
- pm90 7y ago
  > 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.