3 ms·

> Pagination is also awkward, because now you probably want multiple different queries (and thus multiple different resulting documents) so that your 2+ fetches

> Pagination is also awkward, because now you probably want multiple different queries (and thus multiple different resulting documents) so that your 2+ fetches don't retrieve unpaginated information you got the first time around. And it gets worse when nesting comes in. You don't need to write a different graphql query, use variables. Good graphql APIs will expose a start and limit field for Pagination.

masklinn 4y ago
I think you misunderstood the issue. Of course you will use variables for the pagination itself, the issue is that your head of line query will be grabbing other fields than the paginated one. You don't want to repeat these fetches in the followup queries, they're redundant, and assuming the API is rate-limited they will decrease your query budget for no value. That counts double if you're fetching multiple paginated fields (which also adds to the awkwardness).
- searchableguy 4y ago
  I think I got what you are saying now. If you want to get paginated children nodes, then the root will be fetched again which is a problem.
  - masklinn 4y ago
    Indeed. It may not be a huge problem depending on how much data you need, but there are lots of cases where you'd really rather avoid refetching the rest of the root. TBF you could also deal with it using fragments I think, but still, not great.
- obi1kenobi 4y ago
  Agreed — consider what happens when you have a node(start: Int, limit: Int) inside or alongside another such node with start and limit. Your pagination is now two-dimensional, with each node's start/limit as points on its own axis. Now add a third node to the query. Now you have three-dimensional pagination. This quickly goes off the rails. Try writing a generic N-dimensional paginator for such a query to see why it's difficult. Even designing a sensible and reasonably flexible API for one is a headache.
PaulHoule 4y ago
Pagination is a bear. Most of the simple ways of doing it with SQL are problematic. In these docs https://docs.spring.io/spring-batch/docs/current/reference/html/index.html https://docs.spring.io/spring-batch/docs/current/reference/h... there is some discussion of the problems and some answers that go back to the mainframe era.
- marcosdumay 4y ago
  The server side of pagination is really complex if you want to make sure all the results are returned exactly once. If that's your case, consider not paginating at all. But very often, a result missing or duplicated in a few queries isn't a showstopper. On that case, pagination is very simple.
  - PaulHoule 4y ago
    Spring Batch covers the cases where you have to get the right answer! That is you are "full scanning" and making a report or doing something like a reconciliation process in a financial institution, it is not like some image boards where there is a link to the 1781th page of images but it spends forever loading it if you click on it.

masklinn 4y ago

I think you misunderstood the issue. Of course you will use variables for the pagination itself, the issue is that your head of line query will be grabbing other fields than the paginated one. You don't want to repeat these fetches in the followup queries, they're redundant, and assuming the API is rate-limited they will decrease your query budget for no value. That counts double if you're fetching multiple paginated fields (which also adds to the awkwardness).

searchableguy 4y ago
I think I got what you are saying now. If you want to get paginated children nodes, then the root will be fetched again which is a problem.
- masklinn 4y ago
  Indeed. It may not be a huge problem depending on how much data you need, but there are lots of cases where you'd really rather avoid refetching the rest of the root. TBF you could also deal with it using fragments I think, but still, not great.
obi1kenobi 4y ago
Agreed — consider what happens when you have a node(start: Int, limit: Int) inside or alongside another such node with start and limit. Your pagination is now two-dimensional, with each node's start/limit as points on its own axis. Now add a third node to the query. Now you have three-dimensional pagination. This quickly goes off the rails. Try writing a generic N-dimensional paginator for such a query to see why it's difficult. Even designing a sensible and reasonably flexible API for one is a headache.

PaulHoule 4y ago

Pagination is a bear. Most of the simple ways of doing it with SQL are problematic. In these docs https://docs.spring.io/spring-batch/docs/current/reference/html/index.html https://docs.spring.io/spring-batch/docs/current/reference/h... there is some discussion of the problems and some answers that go back to the mainframe era.

marcosdumay 4y ago
The server side of pagination is really complex if you want to make sure all the results are returned exactly once. If that's your case, consider not paginating at all. But very often, a result missing or duplicated in a few queries isn't a showstopper. On that case, pagination is very simple.
- PaulHoule 4y ago
  Spring Batch covers the cases where you have to get the right answer! That is you are "full scanning" and making a report or doing something like a reconciliation process in a financial institution, it is not like some image boards where there is a link to the 1781th page of images but it spends forever loading it if you click on it.