
You Shouldn’t Use Offset and Limit for Your Pagination - kiyanwang
https://medium.com/swlh/why-you-shouldnt-use-offset-and-limit-for-your-pagination-4440e421ba87
======
core-questions
So the author suggests I use a WHERE clause like "id > X LIMIT Y".

What if the table view that I am returning data for is not sorted by the
primary key? What if it is sorted by a different column, or by a set of
columns in priority order? What if there's no numeric key, but rather a GUID?

~~~
johnsonjo
I think your confusion lies in how you are supposed to give this information
to the backend with a simple cursor. The cursor can be whatever you want it to
be and used however you decide to do your query. Your cursor is an opaque
string usually a base64 encoded string that looks like an ID, when in fact
what it really is, is something that serialized to a string. Like say your
data for your query can be expressed as an object well all you have to do is
serialize that object to a string and by making it JSON or some other
serialization format then you encode it with base 64 and viola you have a
cursor. When you need to deserialize it like when the client sends you the
cursor and you have to make the query something else like say it gets
undecoded from base 64 and you expect it to be JSON then you could parse the
JSON and have a regular object.

With that said though you shouldn’t leak your implementation details to your
Frontend. In other words the Frontend should just treat the cursor as an ID
and receive and send back cursors unchanged.

Even though you may not be using GraphQL if you have a lot of questions about
this GraphQL relay has an excellent explanation in a spec about pagination and
cursoring and that page is where I learned most of what I know about Cursoring
[1]. That page also includes pseudo code and detail on how you do before
cursor and after cursor queries and first N or last N selections.

[1]: [https://relay.dev/graphql/connections.htm#sec-
Cursor](https://relay.dev/graphql/connections.htm#sec-Cursor)

