A Typesense design question, anyone can chime in w...
# community-help
a
A Typesense design question, anyone can chime in with ideas: 🙂 We have a Typesense setup with around 4M items, using a number of filters and facets. We want to implement a "Viewed record" type of feature and that should optionally not come up in the search results. This would be at a per-user level. And we would want to have more features in the future where we will have to create user level lists of search results. Option 1: We index this information back to Typesense, and each user has a default filter applied. Which we have available in our DB. I did see scoped search keys to apply the default filters at a user level that would be similar. This puts load on our Typesense syncing data and it will keep increasing with each such feature. Not sure how scalable this is at a filter level as well. Would it be fine to have close to 10K users in one filter? Option 2: We fetch results from Typesense and apply our own filters at a user level to the data from Typesense. If we do this we lose the ability to directly use InstantSearch on the FE which makes it more tedious to maintain. Thoughts on any of the options or any other option that would be better? Appreciate any thoughts.
j
We’ve added a Join feature in
0.26.0.rc11
that might be helpful here: https://gist.github.com/kishorenc/037314619c3104970ae703b25aff2f51
a
Thanks will check it out.
s
is there a way to test it? can't find this branch or tag on github?
j
On the downloads page, if you change the version number to
0.26.0.rc11
for any of the artifacts (except for homebrew) you should be able to download the appropriate package. If you’re on Typesense Cloud, we can do the upgrade for you from our side if you email support at typesense dot org. We haven’t yet exposed self-service upgrades for the 0.26.0.rc series, to avoid confusion with the 0.25.0.rc series
👀 1