2 ms·

If I write an API that exposes the resources A,B and C. Now I use graphql to access a subset of all of those resources, doesn’t this just mean that I have writt

by he0001 7y ago

If I write an API that exposes the resources A,B and C. Now I use graphql to access a subset of all of those resources, doesn’t this just mean that I have written the wrong API? That I would ditch A,B and C and write a resource D which just did that I wanted?

underwater 7y ago
You can make an API that exposes exactly what a client needs, but then the server/client are tightly coupled (and it's not RESTful). What happens when you have multiple clients, and long lived releases with differing requirements.
- he0001 7y ago
  But that’s not what I mean. I mean that your original resources are not the the actual ones you should expose. Hence you have designed your API wrong. And I don’t agree that a resource becomes more tightly coupled if you write it right. It is a resource after all.
  - tracker1 7y ago
    Just because requirements change, doesn't automatically imply the original design was bad.
    - 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.
        7y ago

by he0001 7y ago

underwater 7y ago

You can make an API that exposes exactly what a client needs, but then the server/client are tightly coupled (and it's not RESTful). What happens when you have multiple clients, and long lived releases with differing requirements.

he0001 7y ago
But that’s not what I mean. I mean that your original resources are not the the actual ones you should expose. Hence you have designed your API wrong. And I don’t agree that a resource becomes more tightly coupled if you write it right. It is a resource after all.
- tracker1 7y ago
  Just because requirements change, doesn't automatically imply the original design was bad.
  - 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.
        7y ago