> 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 availa

> 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.