3 ms·

> 1. Fewer API round trips compared to REST. Why? This is always my chief complaint about GraphQL: there is no reason it should take fewer trips than directly

> 1. Fewer API round trips compared to REST. Why? This is always my chief complaint about GraphQL: there is no reason it should take fewer trips than directly hitting an endpoint unless you're structuring everything very rest-y in which case you're doing it wrong and GraphQL is a bandaid (and you'd still probably make the same amount of trips unless you're heavily caching things). IMO. > 2. Clients only download the data they need. Most third party APIs let you specify what fields you want via a query string or post variable which amounts to the same thing. Honestly I think if people stopped trying to force REST into everything and just made RPC like calls to HTTP we'd have far less of a need for GraphQL. Don't get me wrong, I still think GraphQL is pretty cool for third party access in some respects but I don't think it's as useful as a lot of people make it out to be.

biggestdecision 7y ago
Sure, it's possible to setup a REST api with those features (return full objects for fields rather than ID's, client specifies which fields to return in the query). But then you've basically just built a graphQL api. Any syntax you pick for allowing the client to specify which (nested) fields to return is going to look like a graphQL query. And using graphQL gives you some nice tools to use on the client side.
- BinaryIdiot 7y ago
  > But then you've basically just built a graphQL api Not really. The type of API where you specify what you want and the API itself included whatever data you need in an RPC fashion has been around for decades, I feel weird calling it a "graphql api". Ultimately GraphQL gives you some tools. The developer just has to figure out if those tools make up for the additional overhead (processing, size, training, etc). Sometimes it'll be justified I just think more often then not it really isn't.
  - biggestdecision 7y ago
    Sure it's not a new concept. But on the web graphQL is the most prominent implementation of that concept. You can roll your own version of the concept, but why bother when a perfectly serviceable one already exists? With already written client & server implementations in your language of choice?
  - wereHamster 7y ago
    > [other types of APIs] has been around for decades GraphQL is indeed not a new invention. It's a standardisation of existing ideas, that has been given a particular name, and a whole community of people who are building tooling around it. If you tell me you are using/implementing GraphQL then I immediately know what to expect. I know which tools I can use, I know you have a schema, I know I can run queries and the syntax of those etc. But if you tell me that you are using a REST/HATEOAS/RPC with some particular query syntax then I first have to spend a day reading through the documentation to understand the API.
    - chii 7y ago
      > REST/HATEOAS/RPC ... I first have to spend a day reading through the documentation to understand the API. i think you're giving graphql too much credit, and give too little to REST. The schema of graphql is going to require just as much reading up and domain knowledge as the REST api.
viraptor 7y ago
You only get the same amount of API trips as graphql if you support the use case of every current API user. And the one that will start tomorrow. And one after that. Etc. The great thing here is that you don't have to anymore - you automatically support them all (or close to). And if it saves you from writing and documenting each of those new endpoints, that's a win at least in development time for me.

biggestdecision 7y ago

Sure, it's possible to setup a REST api with those features (return full objects for fields rather than ID's, client specifies which fields to return in the query). But then you've basically just built a graphQL api. Any syntax you pick for allowing the client to specify which (nested) fields to return is going to look like a graphQL query. And using graphQL gives you some nice tools to use on the client side.

BinaryIdiot 7y ago
> But then you've basically just built a graphQL api Not really. The type of API where you specify what you want and the API itself included whatever data you need in an RPC fashion has been around for decades, I feel weird calling it a "graphql api". Ultimately GraphQL gives you some tools. The developer just has to figure out if those tools make up for the additional overhead (processing, size, training, etc). Sometimes it'll be justified I just think more often then not it really isn't.
- biggestdecision 7y ago
  Sure it's not a new concept. But on the web graphQL is the most prominent implementation of that concept. You can roll your own version of the concept, but why bother when a perfectly serviceable one already exists? With already written client & server implementations in your language of choice?
- wereHamster 7y ago
  > [other types of APIs] has been around for decades GraphQL is indeed not a new invention. It's a standardisation of existing ideas, that has been given a particular name, and a whole community of people who are building tooling around it. If you tell me you are using/implementing GraphQL then I immediately know what to expect. I know which tools I can use, I know you have a schema, I know I can run queries and the syntax of those etc. But if you tell me that you are using a REST/HATEOAS/RPC with some particular query syntax then I first have to spend a day reading through the documentation to understand the API.
  - chii 7y ago
    > REST/HATEOAS/RPC ... I first have to spend a day reading through the documentation to understand the API. i think you're giving graphql too much credit, and give too little to REST. The schema of graphql is going to require just as much reading up and domain knowledge as the REST api.

viraptor 7y ago

You only get the same amount of API trips as graphql if you support the use case of every current API user. And the one that will start tomorrow. And one after that. Etc. The great thing here is that you don't have to anymore - you automatically support them all (or close to). And if it saves you from writing and documenting each of those new endpoints, that's a win at least in development time for me.