Search tool: pagination

[thomaspiller]

Paging does not work very well when time filters are applied.
Indeed, the number of pages (blue circles) does not correspond to the number of views returned by the Search tool.
It is possible that it is the same in other situations.

[fxi]

Sadly, I was misled by the meaning of nbHits to build the requested pagination system.This seems to be only impacted by the use of filters, which are set in our date filtering feature.

1. Offset is presented as useful for pagination, but meilisearch is not suitable for finite pagination.
2. nbHits does not return a precise value, not like algolia's nbHits. The confusion is reported here.. I still don't fully understand the purpose of 'nbHits', though.

This is blocking, as it would mean that the specs would not be fulfilled, and the tool should be ... rebuilt with another system.

Nothing seems to be on track to get accurate nbHits in prod soon, on meiliSearch side. Maybe – as seen in a laravel scout integration issue – at the end of 2021.

Solutions:

• Minimalist pagination. Replace the pagination system by... next/previous buttons with unforeseeable state, as per recommended in an issue, outside their documentation
• Proxy pagination Wrap meilisearch API in our API : from nodeJS, request docs from meilisearch server side with unlimited number of results ( performance issue to be expected > 1000 ), and implement chunks and pagination in the response ourself. Not very elegant, and the client side helper + tokens would not be usable anymore from our UI – but still available as external service, e.g. https://search.mapx.*
• PostgreSQL Rebuild the backend on top of postgres fulltext search, as I've done for gemet search: less performant, but full customisation possible. Token / authentification should be rewritten too. Pre-made PostgreSQL materialised views + optimised indexes could improve performance, too.
• Hunt for another tool Use another tool, like typesense, elastic search, redis-search, or something else..