It's not really a query language. Certainly not a general purpose query language. It's more of a somewhat flexible RPC, honestly.
It smells like a query language from a distance, but when you get close it smells much more of SOAP.
For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on their side. I have to get all colors of Widgets and filter it myself. The amount of unessessary data then can really multiply when you're getting the children and children's children of those widgets.
Having ported a number of APIs connectors from REST to GraphQL, I can say it has certainly greatly reduced the number of requests I've needed to make, but has often also greatly increased the amount of actual bytes I've received, particularly the bytes I don't need.
Something like datalog would have been much more impressive, but then the burden of implementing a parser for your upstream services would have probably been way too much of a burden. It's too general to be useful :(
Maybe GraphQL is not the best specification for what a real query language looks like, but it's enough for most of CRUD use cases. Thanks GOD i can say goodbye to the ugly REST.
It smells like a query language from a distance, but when you get close it smells much more of SOAP.
For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on their side. I have to get all colors of Widgets and filter it myself. The amount of unessessary data then can really multiply when you're getting the children and children's children of those widgets.
Having ported a number of APIs connectors from REST to GraphQL, I can say it has certainly greatly reduced the number of requests I've needed to make, but has often also greatly increased the amount of actual bytes I've received, particularly the bytes I don't need.