#community-help

Dynamic Facets in Typesense Cloud Version and Optimizing Performance

TLDR Andrew asked about dynamic facets in Typesense. Jason gave in-depth explanations and confirmed that Typesense API already supports dynamic facets. Alex inquired on improving performance and SSR support, and Jason suggested server-side rendering and caching for optimized performance.

Powered by Struct AI

1

14
11mo
Solved
Join the chat
Sep 29, 2022 (13 months ago)
Andrew
Photo of md5-e787df664e9cf1bb94f37d4a96c4ea05
Andrew
01:36 PM
Hi - been really happy with the cloud version of Typesense. Terrific product! Feature question. Does Typesense support (or plan to support) the notion of dynamic facets like you might see in an eComm store? Where depending on the products/categories returned, the facet options change.
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
03:28 PM
Thanks Andrew!

You can already do dynamic facets with the Typesense API - if you specify all the fields across all product categories in the facet_by field, depending on which products are in the results, only facets for those products are returned in the response.
03:29
Jason
03:29 PM
Alternatively, if you need to explicitly control over which fields should show up as facets in the response for each category, you could store a mapping of category to list of facet fields in a JSON structure in some headless CMS system, fetch that on page load for a category page and use that subset of fields to query Typesense
Andrew
Photo of md5-e787df664e9cf1bb94f37d4a96c4ea05
Andrew
07:32 PM
Thank you will give this a try!

1

Oct 28, 2022 (12 months ago)
Alex
Photo of md5-dc362c4060d01d7ad6c9211157de3d69
Alex
05:21 PM
There is cases where the facets are not known at coding time, they might change during data load for instance, are not based on categories etc. And impossible to group into sets. But the largest issue is performance. Is there any RoadMap for this feature in TS?
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
05:38 PM
We plan to support facet_by: * in the near future as part of this: https://github.com/typesense/typesense/issues/612
Alex
Photo of md5-dc362c4060d01d7ad6c9211157de3d69
Alex
07:05 PM
Thanks Jason, I would love to test that when it's being developed 🙂 Have you come across any implementations that would maximize performance and minimize the amount of data being sent to the client? Other then next.js?
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
08:27 PM
In general, if you can do server-side rendering of your category pages and cache the generated HTML in your CDN, that will be fastest in terms of performance
08:28
Jason
08:28 PM
This way you’re avoiding calls at runtime to fetch data from the users’ browser
08:28
Jason
08:28 PM
Next.js is just one framework that helps you do this, but you can do this yourself as well
Alex
Photo of md5-dc362c4060d01d7ad6c9211157de3d69
Alex
11:08 PM
I was thinking of something like stopIfEnoughMatches if that was applicable to SSR. If for instance the search results contain upwards of 100KB of data (in which case next.js will complain that it's not optimal) and we don't actually need all that data to render the initial UI. Just a fraction of that data. And only in the cases when the user keeps on paginating do we actually need more chunks of data. So I guess my question is what approach would make for the most responsive initial UI?
Nov 01, 2022 (12 months ago)
Alex
Photo of md5-dc362c4060d01d7ad6c9211157de3d69
Alex
07:47 AM
To answer my own suggestion: seems per-page is not working properly in my SSR setup (so more data retrieved then required to render the UI). Same concept could also be applied to #of facets and #of values retrieved, when doing facets=*. To retrieve the top X most relevant for initial UI render, and 'show more' for paging to next set. Algolia might support that soon.
Nov 07, 2022 (11 months ago)
Alex
Photo of md5-dc362c4060d01d7ad6c9211157de3d69
Alex
10:51 AM
I was wondering if TypeSense is planning to provide a cloud option with SSR in the future? Having application code close to the TS cluster would minimize the round trip delay.
Jason
Photo of md5-8813087cccc512313602b6d9f9ece19f
Jason
07:19 PM
From Typesense’s perspective, we provide an API that can be called from anywhere. We offer the SDN (Search Delivery Network) feature which allows you to provision nodes in multiple geographic regions and have requests routed to the node that’s close to the request origin geo location. Beyond that, SSR is one specific way to call the Typesense API and is outside the scope of what Typesense offers as an API service. So you would have to use some other platform like say Vercel / Render that offers SSR and then pick Typesense Cloud regions close to the region that you provision your SSR app in. This way the request will go from Vercel/Render straight to the node that’s closest, reducing latency