4 ms·

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 produ

I haven't used it a lot but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Also, as I understand it, when implemented properly, you can get more complex (?) data back. For example, instead of getting 10 orders, and then 10 more requests for the items for each order, you can make a single request and get both in a single response. I believe both concepts apply to creates / updates as well.

timr 4y ago
> but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go hog-wild with the GQL). Also, I don't think I've ever had a situation in my career where loading name and price is a significant burden over either field individually. On the other hand, it's a huge burden to have to implement the back-end system that supports a fully orthogonal, structured query language for the UI. To be fully charitable to the argument you're making, probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. ...but now you have N problems. Your web app has become an ad-hoc distributed query language executor, and you have to think about the semantics and load implications of all of that.
- lmarcos 4y ago
  > probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. That's the only reason why teams use GraphQL. Decoupling taken to the extreme.
mattmanser 4y ago
That's not an advantage, from the DB side the two queries are indistinguishable because they use the same indexes. They will take virtually the same CPU to complete. If your user has authorization to access this extra data, the actual cost of sending those extra fields properties over the wire is ridiculously trivial. Think a kilobyte or two, if not a few bytes. Any justification you think you have for just sending the name + price is utter bullshit. You would save vastly more in bandwidth by not sending whatever dumb graphql code you wrote as part of your front-end build. That is, unless you are Facebook or Google and have already optimized the hell out of your front-end libraries. Which I guarantee you aren't and haven't done.
- nonethewiser 4y ago
  Not at all - removing select “*” from queries is perhaps the lowest hanging fruit for optimizing queries. https://stackoverflow.com/a/25093454 https://stackoverflow.com/a/25093454 I agree that GraphQL is often overkill but specifying fields is powerful and sometimes a big boon.
  - mattmanser 4y ago
    That's not true unfortunately. Posting a SO Question that's been upvoted by 24 people in a decade is not evidence. Think about this a bit more, those are LOCAL network calls you're talking about. Not calls over the internet. It doesn't matter. Obviously if there's a massive blob in your DB table you're not going to be sending it up regardless if you are using graphQL or not.
- chiefalchemist 4y ago
  I'm not worried about the DB. Less down the pipe to the browser or app means the user can get to see something sooner. It also mean less for the hardware / browser + JS to swallow. Minor? Maybe. Until you have users with less powerful mobile devices using less than ideal wifi / internet connections. If work provides you with a new device (either as a company perk or because you're well paid) and you live in a major city where mobile data speeds are great these things don't matter. For most everyone else they do. I suppose this explains why so many mobile experiences are so bad? People like you feel the user experience is "utter bullshit". Shame on you.

timr 4y ago

> but one of the benefits of GraphQL that caught my eye is you get to specify what you want returned. So, for example, instead of 20 product objects (all available properties) you can get 20 products with name and price. Sort of (the sibling comment explains well why this example is an illusion). But even if this were an advantage, you have to implement the logic (simple in this case, but not so simple once people go hog-wild with the GQL). Also, I don't think I've ever had a situation in my career where loading name and price is a significant burden over either field individually. On the other hand, it's a huge burden to have to implement the back-end system that supports a fully orthogonal, structured query language for the UI. To be fully charitable to the argument you're making, probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. ...but now you have N problems. Your web app has become an ad-hoc distributed query language executor, and you have to think about the semantics and load implications of all of that.

lmarcos 4y ago
> probably the real reason people do this is because they want to decouple development between Team UI and Team Product and Team Pricing, and it's just "easier" to expose "web SQL" to Team UI and let them go nuts, rather than sitting down with them an exposing targeted endpoints that give them exactly what they need. That's the only reason why teams use GraphQL. Decoupling taken to the extreme.

mattmanser 4y ago

That's not an advantage, from the DB side the two queries are indistinguishable because they use the same indexes. They will take virtually the same CPU to complete. If your user has authorization to access this extra data, the actual cost of sending those extra fields properties over the wire is ridiculously trivial. Think a kilobyte or two, if not a few bytes. Any justification you think you have for just sending the name + price is utter bullshit. You would save vastly more in bandwidth by not sending whatever dumb graphql code you wrote as part of your front-end build. That is, unless you are Facebook or Google and have already optimized the hell out of your front-end libraries. Which I guarantee you aren't and haven't done.

nonethewiser 4y ago
Not at all - removing select “*” from queries is perhaps the lowest hanging fruit for optimizing queries. https://stackoverflow.com/a/25093454 https://stackoverflow.com/a/25093454 I agree that GraphQL is often overkill but specifying fields is powerful and sometimes a big boon.
- mattmanser 4y ago
  That's not true unfortunately. Posting a SO Question that's been upvoted by 24 people in a decade is not evidence. Think about this a bit more, those are LOCAL network calls you're talking about. Not calls over the internet. It doesn't matter. Obviously if there's a massive blob in your DB table you're not going to be sending it up regardless if you are using graphQL or not.
chiefalchemist 4y ago
I'm not worried about the DB. Less down the pipe to the browser or app means the user can get to see something sooner. It also mean less for the hardware / browser + JS to swallow. Minor? Maybe. Until you have users with less powerful mobile devices using less than ideal wifi / internet connections. If work provides you with a new device (either as a company perk or because you're well paid) and you live in a major city where mobile data speeds are great these things don't matter. For most everyone else they do. I suppose this explains why so many mobile experiences are so bad? People like you feel the user experience is "utter bullshit". Shame on you.