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 a

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