[Areibman]

It totally depends on your use case. Indeed, the best perk, as you've pointed out, is the ability to reduce the quantity of data that runs over the wire. If well-configured, then GQL certainly makes network usage heavy mobile apps much faster. This was the main impetus behind why Facebook decided to build it.

If you're willing to add massive technical overhead to solve this, then GraphQL may be worth a shot.

[philliphaydon]

But if you’re the only consumer of the api then it doesn’t help reduce data, unless your UI is configured to show different amounts of data.

It also doesn’t make network requests faster. I would argue it’s slower when returning the same data between a rest api and graphql. The difference is you don’t do unnecessary joins when you don’t need data. (Since most graphql apis are in front of a relational database anyway)

[kossae]

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.

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