Saving bandwidth is really not the actual super power. The main advantage is being able to save network requests by fetching all required data in the same request.
> The main advantage is being able to save network requests by fetching all required data in the same request.
This is not really GraphQL's selling point.
GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want.
The promise is that frontend teams simply put together a query and the server magically returns what they want.
Of course the people promising this magic just so happen to be the same people trying to sell you backend services.
I know I can make an API endpoint in Rails equally as fast as writing a query in GraphQL and the code needed to use it. I don't really buy into GraphQL yet since I have not come across a strong enough advantage of using it in my carrier. Although I do see the advantage of basically being able to run SQL through the browser. Unfortunately it is just one of may technologies over hyped by JavaScript developers.
Agreed - REST APIs can include a field mask or similar for sparse selection on a single entity but you'll still need several requests to fetch fields on related entities.
This is not really GraphQL's selling point.
GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want.
The promise is that frontend teams simply put together a query and the server magically returns what they want.
Of course the people promising this magic just so happen to be the same people trying to sell you backend services.