Response cache with backend search

[PaulWild]

Description

Our company is currently utilising a backend search as described by https://www.algolia.com/doc/guides/building-search-ui/going-further/backend-search/in-depth/backend-instantsearch/js/.

Implementing this as far as I can tell means that these requests aren't cached in the client's inbuilt responseCache.

Is there any guidance/ability to hook up custom searches to the responseCache? Would something like this work? :

export const customSearchClient = {
  ...algoliaSearchClient,
  async search<TObject>(requests: readonly MultipleQueriesQuery[]) {
    const key = { requests };

    return algoliaSearchClient.transporter.responsesCache.get(key, async () => {
      const response: Readonly<Promise<MultipleQueriesResponse<TObject>>> = customServerRequest()

      await algoliaSearchClient.transporter.responsesCache.set(key, response);
      return response;
    });
  }

Client

Search

Version

all

Relevant log output

No response

[shortcuts]

Hey, our clients expose an options parameter that allows you to define a responsesCache or requestsCache, you can leverage it like so by using our cache helpers exposed in @algolia/client-common, or you can add your as long as it implements this interface

[PaulWild]

Thanks for the message, That's not quite what I am asking. As we have completely overwritten the search function (as described in the link I posted) we are now getting the caching provided out the box if we were talking to algolia direct.

We don't want to create our own cache, are happy with the defaults this is just about can we leverage the caches in our custom search function.

[philwolstenholme]

@shortcuts we're considering making this change to use the Algolia responsesCache cache in our custom search client. Does this look okay to you?

diff --git a/src/components/AlgoliaSearch/AlgoliaSearch.tsx b/src/components/AlgoliaSearch/AlgoliaSearch.tsx
index 9b0b10388b6930662093a796d7770e1e4d4eabef..ef11fc45d82ab7ceb9fb035bf736dc22b11af278 100644
--- a/src/components/AlgoliaSearch/AlgoliaSearch.tsx
+++ b/src/components/AlgoliaSearch/AlgoliaSearch.tsx
@@ -91,17 +91,26 @@ const algoliaSearchClient = algoliasearch(appId, apiKey);
 
 export const customSearchClient = {
   ...algoliaSearchClient,
-  search<TObject>(requests: readonly MultipleQueriesQuery[]) {
-    const response: Readonly<Promise<MultipleQueriesResponse<TObject>>> = nextRequest()
-      .post(requests, '/api/algolia/search')
-      .json();
-    return response;
+  async search<TObject>(requests: readonly MultipleQueriesQuery[]) {
+    const key = { requests };
+
+    const result = await algoliaSearchClient.transporter.responsesCache.get(key, async () => {
+      const response: MultipleQueriesResponse<TObject> = await nextRequest()
+        .post(requests, '/api/algolia/search')
+        .json();
+
+      await algoliaSearchClient.transporter.responsesCache.set(key, response);
+      return response;
+    });
+
+    return result;
   }
 };

[shortcuts]

Hey, sorry for the delay

Thanks for the message, That's not quite what I am asking. As we have completely overwritten the search function (as described in the link I posted) we are now getting the caching provided out the box if we were talking to algolia direct.

Sorry I thought you were sharing backend code for some reason, I just realized it's the frontend implementation here. For the proposed solution of #1575 (comment) you should stringify the key you pass to the cache, but it should work as expected.

I believe the reason you'd like to leverage caching on the frontend is to also reduce the api calls made to your backend? If you want to go with a more "native" solution you can also use custom hosts with your backend address, so that you don't have to override the search method, our transporter will call your backend accordingly and leverage the built-in cache mechanism as well.