The idea is that you can select the exact data fields you need for your UI. In a traditional REST-like response, say for a User model, you may receive all data (within authorization limits) about the user in the response when all you needed was the first_name field. With GraphQL you would just receive first_name without the rest of the unneeded fields, thus reducing the amount of data sent.
If you’re the only consumer of your api then why are you exposing more data than you need? I’ve never seen an internal rest api that was 100% restful. It was restLike.
So if you have consumers of your api then allowing them to pull only what they need makes sense. But for an api where you are the only consumer, it makes no sense.
If you have more than one developer working on different features, it’s inevitable they’re going to need different data. Unless you have a tight feedback loop between frontend and backend devs, you’re going to end up with pending unresolved issues requesting they add another field to be returned on a specific, custom “rest-like” endpoint. If you instead put the onus on the frontend to allow arbitrary field requests (of course within limits, typed and auth’d), this is no longer an issue. Of course the api has to have a schema defined, so there could be a request for a new field to be added there. But if all your endpoint returns is what we need NOW, then you will inevitably have to add more data to the endpoints later with new features. This isn’t of course the only benefit of GraphQL, but it’s certainly a nice convenience for those having to make those requests.
This! So many native/web apps have APIs which are only consumed by that app and are over architected chasing "REST". Just make an endpoint for the data you're fetching and move on!
There are so many apps that go from function to rest to function.
