Reason for that is that I am implementing a full-text search that requires paging through the search result and therefore I have to build my pages manually (on the API) by giving them meaningful next/after cursors.
I could of course fall back to a custom cursor, but since my frontend already uses the cursor logic for regular paging I hoped I could avoid a custom solution only for my full-text search feature. That would also allow me to use existing GraphQL queries out-of-the box.
Unfortunately, there is no way to manually build a cursor using the same technique that the GraphQL API uses. The cursors you shared are base64-encoded binary structures that embed the state of the set used to paginate results. The set state includes details you don’t have access to besides the cursor itself.
Several users have asked for cursor improvements. You might vote for their feature requests, which would help us to prioritize the work:
Thanks Ewan. I wonder that there’s only me voting this request up …
I really struggle building a generic solution for a full text search here because I need to utilize different indexes and each index has its own cursor structure (basically a list of all values).
I tried to implement a serialization approach but it does not work with all these Ref types contained within the cursor. I have read that there are toJSON and parseJSON shipped with the JS driver but they are not public (supposedly because they’re part of the internal wire protocol?)
From my point of view I am stuck with no good option here:
I cannot use GraphQL and indexes because they can only apply equality to terms (no LIKE)
I cannot use GraphQL and UDF because I can only filter existing pages, but cannot create own pages based on search results.
I cannot create GraphQL cursors myself
I cannot implement an index based server side solution because the cursors cannot be serialized
I do have working solution using an index without any values loading all documents service-side in order to perform the full-text search. But that is obviously not very efficient.
I upvoted the feature request but if I am not completely mislead, I see a very bad developer experience here.
Full text search is not one of Fauna’s strengths. I do know that several users have managed to create a custom solution by combining Fauna with ElasticSearch, however, I don’t know any details of their implementation.
I cannot implement an index based server side solution because the cursors cannot be serialized
If you use FQL, instead of GraphQL, you can serialize those cursors. And you would have an easier time crafting a cursor based on generated information, since FQL cursors are tuples formed from index entries: the structure comes from the values definition in the associated index.
…