SSR extracted cache huge file size

[Gitsack]

Hi :) We're running a fairly large nextjs site with lots of pages and run into the issue of urql cache being a very large payload that is sent to the client since it seems to be sent as a whole.

We need SSR content and implemented the solution to provide the extracted ssrCache to the client to be able to use dynamic content like paginations with Urql.

• Is this the expected behavior or is there a check or some sort of treeshaking missing in our implementation that only sends the required cache items for a specific page to the client?
• Or is the suggested solution to clear the cache on each request?
• Or should there be a specific cache for each page which is populated independently? How could that be done?

Our client exchanges

(graphCache is cacheExchange with some custom resolvers, keys etc.):

exchanges: [devtoolsExchange, dedupExchange, graphCache, ssrCache, fetchExchange]

getServerSideProps on index page:

export async function getServerSideProps() {
  
  const { data: pageData } = await ssrCmsQuery({
    query: GetBySlugDocument,
    variables: {
      slug: '/home',
    },
  });

  return {
    props: {
      data,
      urqlState: ssrCache.extractData(),
    },
  };
}

_app.tsx restoring the cached data for client use:

// ...
import { cmsClient, ssrCache, ssrCmsQuery } from '@/lib/urql/client';

function MyApp({ Component, pageProps }) {

  pageProps.urqlState && ssrCache.restoreData(pageProps.urqlState);

  return (
    <AppContext.Provider>
      <Provider value={cmsClient}>
          <Component {...pageProps}  />
      </Provider>
    </AppContext.Provider>
  );
}

Thanks!

[kitten]

Or is the suggested solution to clear the cache on each request?

Please please please, do this 😅 If you don't have a mechanism to clear the cache, it'll continue growing indefinitely. The SSR Exchange is purely to replace client-side results with server-side results once.

The idea isn't to cache them indefinitely, share the cache between users, and to clear the cache, since often a CDN would be much better suited to caching SSR results. So, our recommendation is to re-create the client for each request

If you're sharing the client and results you're also running the risk of leaking authenticated data between requests

[Gitsack]

@kitten Thanks for the quick response! :)

Ok that makes sense if the cache is getting sent without filtering going on in the background, then this definitely should be done differently in our implementation.

So we changed the behavior to recreate ssrCache and clients on each page load once and so far this seems to be the solution. 👍
Thanks again! :)