6 ms·

But that’s the thing. Should you invest in an obsolete API or just change it? If you don’t, you have both an obsolete API and a more complex solution instead of

by he0001 7y ago

But that’s the thing. Should you invest in an obsolete API or just change it? If you don’t, you have both an obsolete API and a more complex solution instead of just changing your API. And if you don’t change your API to adapt to the newer requirements, but use Graphql to “bridge” that problem, you now have a client that’s heavily invested in your old obsolete API with a technology glued to it. To me, that sounds like a bad idea.

tracker1 7y ago
In the case of GraphQL and in the most prolific examples (Netflix and Facebook), you're not considering that the time to setup a GQL interface is less in aggregate than modifying many, many APIs for data that is distributed across varying data stores, often column/kv structures. These are also organizations doing more than just public facing pieces. For example, Netflix has to deal with art, media, and licensing that will vary by location, language and even distribution models under different contract terms for a different region. That's only one aspect of how things work. In the end, an API written for one department may not match the needs of another, and another still may need additional related aggregate data. In the end, would you rather define your data sources once, or communicate API needs across several departments and maintain 3x or more the surface area to support them? edit: I'm not saying GraphQL is appropriate for all scenarios... but I'm saying it is definitely better for many.
- he0001 7y ago
  But graphql cannot do more than the API already does? It’s constrained to the capabilities of the API. Such as if there’s no way of updating a field, graphql won’t do that either? So it can only make over-fetching more efficient? And by what you are saying, it’s more complicated to create a new resource than incorporating several endpoints with graphql, I find it hard to believe.
  - tracker1 7y ago
    Imagine the scenario, where you're a developer on one team and need to consume data owned/orchestrated by another team. YOU don't have access to their data source... you either get a custom API that will be updated when they're able to, their priorities are different from yours and under a different internal organization. With GQL, as long as the source data is defined, you get as much or as little as your queries define. With API only, you're stuck explaining to your boss why you have to wait for another team in another org to let you get to it, because they have other priorities.
    - 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

tracker1 7y ago

In the case of GraphQL and in the most prolific examples (Netflix and Facebook), you're not considering that the time to setup a GQL interface is less in aggregate than modifying many, many APIs for data that is distributed across varying data stores, often column/kv structures. These are also organizations doing more than just public facing pieces. For example, Netflix has to deal with art, media, and licensing that will vary by location, language and even distribution models under different contract terms for a different region. That's only one aspect of how things work. In the end, an API written for one department may not match the needs of another, and another still may need additional related aggregate data. In the end, would you rather define your data sources once, or communicate API needs across several departments and maintain 3x or more the surface area to support them? edit: I'm not saying GraphQL is appropriate for all scenarios... but I'm saying it is definitely better for many.

he0001 7y ago
But graphql cannot do more than the API already does? It’s constrained to the capabilities of the API. Such as if there’s no way of updating a field, graphql won’t do that either? So it can only make over-fetching more efficient? And by what you are saying, it’s more complicated to create a new resource than incorporating several endpoints with graphql, I find it hard to believe.
- tracker1 7y ago
  Imagine the scenario, where you're a developer on one team and need to consume data owned/orchestrated by another team. YOU don't have access to their data source... you either get a custom API that will be updated when they're able to, their priorities are different from yours and under a different internal organization. With GQL, as long as the source data is defined, you get as much or as little as your queries define. With API only, you're stuck explaining to your boss why you have to wait for another team in another org to let you get to it, because they have other priorities.
  - 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.