Support skip/take in addition to after/limit

[omelhus]

Hey,

It would be awesome if the API could support skip/take (or just skip/limit) in addition to the current after/limit. Many external systems are using skip/take, and whilst it's not optimal for deterministic fetching it's enough for when you are just presenting something in a UI (and want page X of N functionality).

Cheers

[Marius Bancila · Accepted solution]

This feature is now available. See https://docs.business.visma.net/docs/features/pagination

[Marius Bancila]

Thinking about this, take is something we already have, except that we call it first/last.

Example for forward pagination:

table(first: 10, after: "...")
{
   items
   {
      col1
      col2
   }
}

 This is conceptually the same as:

table(take: 10, after: "...")
{
   items
   {
      col1
      col2
   }
}

Example for backwards pagination:

table(last: 10, before: "...")
{
   items
   {
      col1
      col2
   }
}

which, again, is conceptually the same as:

table(take: 10, before: "...")
{
   items
   {
      col1
      col2
   }
}

What we need to provide is an extra argument that would first skip N items before taking M:

table(skip: 5, first: 10, after: "...")
{
   items
   {
      col1
      col2
   }
}

 The effect here it would be that given the following dataset:

ID	Name
1	Aaa
2	Bbb
3	Ccc
4	Ddd
5	Eee
6	Fff
7	Ggg
8	Hhh
9	Iii
10	Jjj
11	Kkk
12	Lll
13	Mmm
14	Nnn
15	Ooo
16	Ppp
17	Qqq
18	Rrr
19	Sss
20	Ttt

Suppose that we call this:

• with the after argument, then {Aaa, Bbb, Ccc, Ddd, Eee} are skipped and the return set contains {Fff, Ggg, Hhh, Iii, Jjj, Kkk, Lll, Mmm, Nnn, Ooo}
• with the after argument set at "cursor-of-Jjj", then {Kkk, Lll, Mmm, Nnn, Ooo} are skipped and the return set contains {Ppp, Qqq, Rrr, Sss, Ttt}

This would work the same regardless of the order of the three arguments, skip, first, after. 

Also, this would work the same for backwards pagination, with the arguments skip, last, before.

In the GraphQL context, skip does not make sense alone. Meaning that you are supposed to ask for at least one record after skipping some records. Also, it doesn't make sense that you first take and then skip. That should translate into two operations, with the first you take N records, and with the second you first skip M then take K more.

[omelhus]

Skip seldom make sense alone. All I'm asking is that you build in skip/first before you decide to change the after/before to something else. This enables me to create a traditional pagination with number of pages etc, and it works well in the current setup.

[Marius Bancila]

But do you have any suggestion for how the skipping should work? Any concrete feedback on my proposed solution?

[omelhus]

I don't see any reason for skip and after to be used together, really. I'd use skip/first for pagination and first/after for going through a complete data set. I'm not seeing the use case for them being used together, but if it's easier to support it I see no reason not to.

[Marius Bancila]

So basically you want skip to just return you a cursor to the beginning of the set you're interested it.

[omelhus]

Would be cool if you could implement skip/take before changing after to something else. It's working as expected for me now, so when/if you change from base64(index) please consider adding skip: index.

[Marius Bancila]

before and after are cursors. Today they are base64encoded indexes. Tomorrow they can be something else. It's an implementation detail. I can't advise you to rely on that.

Currently, we don't have the mechanisms to implement this directly (without actually fetching data and skipping/taking) but it's something we can discuss about.

[omelhus]

Alright, so after digging in for a minute it seems that after is just a base64 version of skip. I'm content then 😀

Cool if you can confirm, Marius 😎