Right. Regardless of how you go about doing things, if a UI is going to compose more than one kind of resource (which in reality is pretty much every UI), there's going to be some kind of n+1 problem hidden in there somewhere -- unless you go down the route of building a bespoke endpoint per screen or operation, which isn't the worst thing in the world, but it's not the work I want to spend my time doing when building products.

What GraphQL essentially gives you is a mechanism for providing a specification and getting back an endpoint, either fully dynamically at runtime, or at build-time if using persisted queries.

> but it's a lot easier to fix N+1 issues at the GraphQL resolver level,

It definitely isn't. And, once again, dataloaders are just the first step.

> With REST, you end up either creating ad hoc endpoints or changes to solve each individual problem in isolation, or you end up building a lot more flexibility into your REST API to solve it in a general way

Even with a "general way" your REST endpoint knows what actual request or a type of request it's solving. So, instead of doing several requests to the database where each request is essentially "SELECT *", you'll be doing queries optimised for the specific request type.

And there are many-many other things. Like caching. For which Apollo has to unpack and look into every single request and response, for example (and libraries in other languages don't solve at all).