[shaunpersad]

> Is something going to know to reuse the inflight request so you don't have two identical requests?

I really don't see what GraphQL has to do with this problem. What you're describing are issues that pop up with any external datastore. GraphQL is just a protocol. If there are clients that take care of that type of caching, that's an implementation detail. You can also have REST clients that do the same.

> Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places?

If you knew you needed info about the user as a blog author as well, you could've included that in the users request. Isn't that what you would've done in GraphQL anyway?

I'm not trying to detract from GraphQL's usefulness, but you can accomplish the same things in REST pretty easily too, especially if you control both server and client code.

IMO, GraphQL really shines when you're implementing clients for APIs that you don't already control. In that case, the flexibility is great. But if you're building both the APIs and the clients, REST works (and has worked) pretty easily.

[exogen]

Indeed! I wasn't talking about REST vs. GraphQL at all, but rather the benefit that fancy clients get you (notice I said "systems like what's described in the article", not GraphQL in general). I think that's what the grandparents were talking about, since the boilerplate they were discussing presumably comes from Apollo, not GraphQL. Apollo is a fancy client like you describe.