[jkoudys]

Often the rates I'll end up limiting in rest aren't even bottlenecks at all in graphql. like if I wanted to grab a relationship that hasn't been implemented with its own resource endpoint.

e.g. get all the comments in every article written by one author, I might say `/author/john smith` that returns all their articles, then run an `/articles/{}?include=comments` for each one. That'll run a separate query server-side for each one, which can get very heavy if I'm doing thousands of queries. On the gql this is trivial as `{ author(name: "john smith") { articles { comments `, but because it's one request the server-side fetch can be run _way_ more efficiently. We have dataloaders for the SQL written that'll collapse every big query like this into (often) a `IN (?, ?`... query, or sometimes subselects. Same concept works on any sql or nosql approach. So yeah it might be "a lot" data were it RESTful, but we're not going to bottleneck on a single indexed query and a ~10MB payload.

The real advantage I see for REST in that scenario is that it can _feel_ faster to the end-user, since you'll get some data back earlier. Running a small query on thousands of requests is slower, but you can display the first little one's result to the user faster than a big gql payload,.