https://typesense.org logo
Join Slack
Powered by
I’m implementing <relay cursors> on top of typesen...
# community-help
d
I’m implementing relay cursors on top of typesense results, and it’s being trickier than it should be. relay specs that a result set can start at an arbitrary position inside the collection - an offset - and can specify how many results to take, from that position. This does not correlate very well to pages - was wondering if it’d be possible to add options to support this? ie, from offset X, return Y results (backwards and forwards).
k
Is it possible for you to calculate the offset by using page/per_page this way:
Copy code
offset = (page - 1) * per_page
So for page 1, offset will begin with zero. The number of results to take from that position will be equal to per_page.
d
the offset can be arbitrary, and it’s supplied by the client - hence the trickiness trying to convert “take x results from position y in the collection” into pages and per-page
ie, what’s the page number and per_page for “take 100 results from position 13”? or vice versa?
if I’m missing something obvious, please do say!
k
As long as the client is not going to pick random arbitrary indices and per_page number is going to be a constant, then position / per_page will give the page value right?
d
true. think that might be the simplest way to do it
but it’s not 100% compliant with what the spec intends
k
I think that assumption should hold constant. Adding an alternative way to do pagination might be confusing to people, unless there is a very strong reason to do so, e.g. work around absolutely fails.
The spec follows SQL way of 
offset, limit
convention.
👍 1
d
the relay spec appears to work differently
k
When we designed the Typesense pagination parameter I intentionally went with page and per_page which seemed so much more natural to humans, than thinking in terms of arbitrary offsets.
d
I get both sides. the offset / take idea is helpful in some situations too
in the graphQL context, the nested selections can be extremely heavy, so being able to tune the amount that’s being requested is nice
ie - in our case, we’re enriching the typesense results via a graph database on top
k
I see, got it, I've not used graphql and certainly there might be use cases which haven't forced this issue on us yet.
m
if you take something like graphql-mesh, or any other schema stitching type graph layer, you could start enabling great stuff
We use this to create singular schema's presented in graphql, but stich in restful results and postgres RDB data
with aggregation in the middleware etc
A use case is to be able to for example, query a customers product subscription status from a traditional RDMS, but also return relevant typesense results, the graphql schema will be agnostic of the 2 backend data sources, then present a simple schema to the graphql query api and websocket endpoint
d
that is indeed what we’re doing - but using lacinia to stitch postgres, datomic and typesense data together. works 👌 - apart from the pagination issue.
we’re gradually retiring postgres in favour of datomic, and swapping out resolver functions lets us keep a uniform facade to consumers, which is neat
m
Thats excellent
Love the progressive approach, if you need any help testing anything feel free to ping me
🙌 1
k
We will implement an alternative offset/limit based pagination. Tracking it here: https://github.com/typesense/typesense/issues/591
🙌 1
Open in Slack
PreviousNext
Powered by