4 ms·

GraphQL is extremely badly designed - try to do nested pagination, that's basically unsolvable in a single server roundtrip. The hack of keeping an n-dimensiona

by bitL 5y ago

GraphQL is extremely badly designed - try to do nested pagination, that's basically unsolvable in a single server roundtrip. The hack of keeping an n-dimensional array of pointers to cover each level of pagination falls apart with any concurrent changes. And nested pagination pops up often when doing advanced UI on mobile on web.

danjac 5y ago
Efficiency often takes a back seat to Conway's Law.
infogulch 5y ago
The "nested pagination with a single server roundtrip" requirement seems a little odd, I'm not sure why that's necessary or desired. I can imagine an example, a view with a list of users, then expanding one user inline to view a list of their comments. But I don't see why I'd even want this whole nested view to be returned in one round trip, it seems quite wasteful to return the first page of comments for every user before it's expanded. Do you have a better example?
- andrewingram 5y ago
  The need for hitting nested “paged” data structures on first render isn’t that contrived, but I’ve never found myself needing to juggle the cursors, since you’re usually only hitting the first page for the nested ones. Loading subsequent pages would be a standalone query, rather than running the root query again with different cursors. (the example I came up with for this article a few years has a fairly realistic example of nested pages: https://andrewingram.net/posts/optimising-your-graphql-request-waterfalls/ https://andrewingram.net/posts/optimising-your-graphql-reque...)
adsharma 5y ago
What does an ideal solution look like in your view? Do snapshot queries help, so you're protected from concurrent changes? With fquery (https://adsharma.github.io/fquery/ https://adsharma.github.io/fquery/), the problem boils down to constructing a new query with additional where clauses. Because of the property that the shape of the query and the shape of the output are identical, nested queries fit naturally into the system, as opposed to GraphQL <-> SQL where one is nested, but the other is flat, requiring a mapping.
SkyPuncher 5y ago
REST has the same issue.

by bitL 5y ago

danjac 5y ago

Efficiency often takes a back seat to Conway's Law.

infogulch 5y ago

The "nested pagination with a single server roundtrip" requirement seems a little odd, I'm not sure why that's necessary or desired. I can imagine an example, a view with a list of users, then expanding one user inline to view a list of their comments. But I don't see why I'd even want this whole nested view to be returned in one round trip, it seems quite wasteful to return the first page of comments for every user before it's expanded. Do you have a better example?

andrewingram 5y ago
The need for hitting nested “paged” data structures on first render isn’t that contrived, but I’ve never found myself needing to juggle the cursors, since you’re usually only hitting the first page for the nested ones. Loading subsequent pages would be a standalone query, rather than running the root query again with different cursors. (the example I came up with for this article a few years has a fairly realistic example of nested pages: https://andrewingram.net/posts/optimising-your-graphql-request-waterfalls/ https://andrewingram.net/posts/optimising-your-graphql-reque...)

adsharma 5y ago

What does an ideal solution look like in your view? Do snapshot queries help, so you're protected from concurrent changes? With fquery (https://adsharma.github.io/fquery/ https://adsharma.github.io/fquery/), the problem boils down to constructing a new query with additional where clauses. Because of the property that the shape of the query and the shape of the output are identical, nested queries fit naturally into the system, as opposed to GraphQL <-> SQL where one is nested, but the other is flat, requiring a mapping.

SkyPuncher 5y ago

REST has the same issue.