[philliphaydon]

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.

[kossae]

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.

[andrewingram]

It's interesting, because I always argue that first-party usage is GraphQL's sweet spot (over third-party).

To avoid repeating myself, here's a minor tweet thread from a few weeks ago: https://twitter.com/andrewingram/status/1278019358703435777

[vyrotek]

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.

App.Something(5) > /api/something/5 > API.Something(5)

It's OK to just need an RPC web API! Especially really verby ones where you waste time trying to turn everything into a "resource".