7 ms·

I keep seeing stuff like this and wonder where the actual advantage to graphQL is?

kenrose 7y ago
1. Fewer API round trips compared to REST. 2. Clients only download the data they need. No more REST silly patterns like BFF trying to support multiple client needs. Yes, this does make instrumentation and rate limiting harder, but not impossible. It’s akin to using SQL... sometimes the query optimizer does weird things, but declaratively asking for your data is much better than imperatively pulling and joining it yourself.
- BinaryIdiot 7y ago
  > 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.
- tjpnz 7y ago
  >1. Fewer API round trips compared to REST. 2. Clients only download the data they need. No more REST silly patterns like BFF trying to support multiple client needs. In most cases a thoughtfully designed REST API built according to HATEOAS shouldn't exhibit these problems. I've seen too many teams with a flawed understanding of both viewing GraphQL as some kind of silver bullet. Instead of stopping to consider their architecture they just rush out and implement GraphQL only to find themselves having significantly worse performance issues than they were having before.
  - strken 7y ago
    My understanding of the advantage of GraphQL is that it allows you to load a structure like user { groups(first: 10) { posts(first 1) { content author { name address { state } } } } } and have all the round-trips take place within a datacentre, instead of needing to query /user /user/12/groups?limit=10 /groups/34/posts?limit=1 /posts/56 /users/78 /users/78/address and without having to write a separate /top_posts_view endpoint. I don't understand from the description "a thoughtfully designed REST API built according to HATEOAS" what your proposal to solve this problem is.
    - JoachimSchipper 7y ago
      A quick search suggests that GraphQL should usually cause one client -> server -> SQL-server query - i.e. only one network round trip. No?
      - strken 7y ago
        I've only used it to aggregate backend services rather than as an SQL query builder, and this is also how it's used at Facebook. I'd have concerns about writing business logic in resolvers. If I was using it with a single SQL db I'd probably write a separate non-GraphQL layer for business logic and keep the resolvers thin.
        7y ago
- bsaul 7y ago
  I’ve read somewhere GraphQL major use case was in actually building BFF... Unless you’re building one giant graphql enpoint exposing your whole database ?
tepidandroid 7y ago
Along with what kenrose said, imagine the flexibility of being able to request the exact view that you need from the server for any client you have in mind. A perfect view fetched in a single trip -no overfetching or underfetching, no bespoke HTTP endpoints for every new use-case and a self documenting API + type-safety to boot. Some trade-offs are things like more backend complexity, querying complex data (like deeply nested or recursive data structures) becomes harder, limiting exponential query complexity as the data branches out, etc. It also becomes more difficult to predict resource usage and to monitor performance, as the article mentions.
- lkrubner 7y ago
  There is something badly broken with your process for denormalization if you think bespoke endpoints are more work than GraphQL. Presumably you have to denormalize for many internal uses, as well as external ones, so it pays to automate that process till it is both flexible and easily configured and automatic.
  - thom 7y ago
    But you’ve just described a bunch of work to do to achieve what’s GraphQL gives you for free, surely?
    - dmitriid 7y ago
      There’s nothing free. Requesting “any view for any potential client” will most likely cripple your backend because you can’t optimise ad-hoc queries.
      - thom 7y ago
        So in the presumably rare case that this happens can one not just add a new view, map it in the GraphQL schema and still come out far ahead on development time? I just feel like a huge number of people are going to accept lower complexity in the short term with some optimisation to do later. That seems like an fairly sensible and defensible tradeoff. I’ll admit I’m not picturing public APIs though.
true_religion 7y ago
GraphQL is basically well structured RPC calls. So everything you wanted to do with SOAP, with none of the headaches and really nice instrumentation and documentation thrown in as part of the protocol. I'm usually surprised with all the comparisons to REST. It's far more practical and way less dogmatic.
- aleksei 7y ago
  > I'm usually surprised with all the comparisons to REST. I'd say that's because you should mentally substitute RPC whenever you see REST. Basically everyone talking about REST APIs mean RPC over HTTP with nouns in the endpoints.
davnicwil 7y ago
To me, the question is the other way round because the advantages (pointed out by all the other comments in this thread so I won't repeat) are clear, kind of immediately. It's the disadvantages, particularly the 'unknown unknowns' that I wonder about, and that's what's kept me from using it. GraphQL so far seems like the archetypal counter example for the 'use boring stuff' philosophy of software engineering. I kind of hope I'm wrong here, because the advantages are big and pretty cool.
- strken 7y ago
  GraphQL is pretty boring, at least on the server. You give your GraphQL library a schema and tell it how to deal with fields, and then it makes a tree of fields from your query and populates them according to your instructions. It can get "exciting" on the client, particularly with libraries like Apollo. See for example the bug https://github.com/apollographql/apollo-client/issues/1186 https://github.com/apollographql/apollo-client/issues/1186, which took two years to fix. The tooling for persisted queries can also be hard to set up, and they're close to required if you want to expose GraphQL to your client.
  - dmitriid 7y ago
    It’s actually exciting on the server. Ad-hoc queries with unlimited complexity? Check. No caching? Check. No auth? Check.
    - barbellguy97 7y ago
      What do you mean wirh unlimited complexity, no caching oe aithorization? Have you ever used ot server-sody? Because they are all solved problems, except maybe caching in the transport layer, depensing on which forn of caching you're targetting.
      - dmitriid 7y ago
        > What do you mean wirh unlimited complexity, no caching oe aithorization? I mean what I mean exactly. - GraphQL allows ad-hoc queries of unlimited complexity. - Since it's POST requests, there's no caching on the HTTP layer. - Since it's add-hoc queries, it's hard to devise a cache for the DB layer. - There are no easy solutions for either authentication or authorisation for queries (and subqueries and/or fields) > Because they are all solved problems If by solved you mean "busily reinventing the wheel and adding layers and layers of unneeded complexity, and it will only work if you buy into a single vendor's solution such as Apollo". For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached.

1. Fewer API round trips compared to REST. 2. Clients only download the data they need. No more REST silly patterns like BFF trying to support multiple client needs. Yes, this does make instrumentation and rate limiting harder, but not impossible. It’s akin to using SQL... sometimes the query optimizer does weird things, but declaratively asking for your data is much better than imperatively pulling and joining it yourself.

BinaryIdiot 7y ago
> 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.
tjpnz 7y ago
>1. Fewer API round trips compared to REST. 2. Clients only download the data they need. No more REST silly patterns like BFF trying to support multiple client needs. In most cases a thoughtfully designed REST API built according to HATEOAS shouldn't exhibit these problems. I've seen too many teams with a flawed understanding of both viewing GraphQL as some kind of silver bullet. Instead of stopping to consider their architecture they just rush out and implement GraphQL only to find themselves having significantly worse performance issues than they were having before.
- strken 7y ago
  My understanding of the advantage of GraphQL is that it allows you to load a structure like user { groups(first: 10) { posts(first 1) { content author { name address { state } } } } } and have all the round-trips take place within a datacentre, instead of needing to query /user /user/12/groups?limit=10 /groups/34/posts?limit=1 /posts/56 /users/78 /users/78/address and without having to write a separate /top_posts_view endpoint. I don't understand from the description "a thoughtfully designed REST API built according to HATEOAS" what your proposal to solve this problem is.
  - JoachimSchipper 7y ago
    A quick search suggests that GraphQL should usually cause one client -> server -> SQL-server query - i.e. only one network round trip. No?
    - strken 7y ago
      I've only used it to aggregate backend services rather than as an SQL query builder, and this is also how it's used at Facebook. I'd have concerns about writing business logic in resolvers. If I was using it with a single SQL db I'd probably write a separate non-GraphQL layer for business logic and keep the resolvers thin.
      - 7y ago
bsaul 7y ago
I’ve read somewhere GraphQL major use case was in actually building BFF... Unless you’re building one giant graphql enpoint exposing your whole database ?

tepidandroid 7y ago

Along with what kenrose said, imagine the flexibility of being able to request the exact view that you need from the server for any client you have in mind. A perfect view fetched in a single trip -no overfetching or underfetching, no bespoke HTTP endpoints for every new use-case and a self documenting API + type-safety to boot. Some trade-offs are things like more backend complexity, querying complex data (like deeply nested or recursive data structures) becomes harder, limiting exponential query complexity as the data branches out, etc. It also becomes more difficult to predict resource usage and to monitor performance, as the article mentions.

lkrubner 7y ago
There is something badly broken with your process for denormalization if you think bespoke endpoints are more work than GraphQL. Presumably you have to denormalize for many internal uses, as well as external ones, so it pays to automate that process till it is both flexible and easily configured and automatic.
- thom 7y ago
  But you’ve just described a bunch of work to do to achieve what’s GraphQL gives you for free, surely?
  - dmitriid 7y ago
    There’s nothing free. Requesting “any view for any potential client” will most likely cripple your backend because you can’t optimise ad-hoc queries.
    - thom 7y ago
      So in the presumably rare case that this happens can one not just add a new view, map it in the GraphQL schema and still come out far ahead on development time? I just feel like a huge number of people are going to accept lower complexity in the short term with some optimisation to do later. That seems like an fairly sensible and defensible tradeoff. I’ll admit I’m not picturing public APIs though.

true_religion 7y ago

GraphQL is basically well structured RPC calls. So everything you wanted to do with SOAP, with none of the headaches and really nice instrumentation and documentation thrown in as part of the protocol. I'm usually surprised with all the comparisons to REST. It's far more practical and way less dogmatic.

aleksei 7y ago
> I'm usually surprised with all the comparisons to REST. I'd say that's because you should mentally substitute RPC whenever you see REST. Basically everyone talking about REST APIs mean RPC over HTTP with nouns in the endpoints.

davnicwil 7y ago

To me, the question is the other way round because the advantages (pointed out by all the other comments in this thread so I won't repeat) are clear, kind of immediately. It's the disadvantages, particularly the 'unknown unknowns' that I wonder about, and that's what's kept me from using it. GraphQL so far seems like the archetypal counter example for the 'use boring stuff' philosophy of software engineering. I kind of hope I'm wrong here, because the advantages are big and pretty cool.

strken 7y ago
GraphQL is pretty boring, at least on the server. You give your GraphQL library a schema and tell it how to deal with fields, and then it makes a tree of fields from your query and populates them according to your instructions. It can get "exciting" on the client, particularly with libraries like Apollo. See for example the bug https://github.com/apollographql/apollo-client/issues/1186 https://github.com/apollographql/apollo-client/issues/1186, which took two years to fix. The tooling for persisted queries can also be hard to set up, and they're close to required if you want to expose GraphQL to your client.
- dmitriid 7y ago
  It’s actually exciting on the server. Ad-hoc queries with unlimited complexity? Check. No caching? Check. No auth? Check.
  - barbellguy97 7y ago
    What do you mean wirh unlimited complexity, no caching oe aithorization? Have you ever used ot server-sody? Because they are all solved problems, except maybe caching in the transport layer, depensing on which forn of caching you're targetting.
    - dmitriid 7y ago
      > What do you mean wirh unlimited complexity, no caching oe aithorization? I mean what I mean exactly. - GraphQL allows ad-hoc queries of unlimited complexity. - Since it's POST requests, there's no caching on the HTTP layer. - Since it's add-hoc queries, it's hard to devise a cache for the DB layer. - There are no easy solutions for either authentication or authorisation for queries (and subqueries and/or fields) > Because they are all solved problems If by solved you mean "busily reinventing the wheel and adding layers and layers of unneeded complexity, and it will only work if you buy into a single vendor's solution such as Apollo". For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached.