The n+1 problem is real but I do think dataloader is a very ergonomic solution. In a simple REST API using your ORM's preload functionality is even more ergonomic, but in more complex cases I've seen a lot of gnarly stuff like bulk-loading a bunch of data and then threading it down through many layers of function calls which definitely feels worse than the batched calls you make to avoid N+1's in gql.
Re:A REST View of GraphQL
by tomnipotent on Wednesday July 08, 2020 @01:40PM
(#23772209)
> gloss over the n+1 query problem, but I find it to be a major shortcoming of the gql spec.
Why would an implementation detail like n+1 be part of the spec?
Re:A REST View of GraphQL
by cryptonector on Wednesday July 08, 2020 @02:41PM
(#23772944)
The n+1 query problem arises from having an API that doesn't let you express the full query that you want so the server can send you back all the data in one go instead of N+1 goes. The n+1 query problem arises naturally from bad API design. That's a spec problem.
Im happy GQL brought api-contract-type-saftey to a wider audience, but it is similarly solved with swagger/OpenApi/protobuf/et al.
Folks may be interested in dgraph, which exposes a gql api and is not victim to the n+1 problem since it is actually a graph behind the scenes.