Mini cart render and caching strategies

[bobbyshaw]

Hi, first all, I'm pumped for Catalyst. Thanks for the fantastic efforts from everyone involved to get us to this point 👏.

I'll hold my hands up and say that some of the concepts are new to me so I'm doing a bit of a deep dive as I set up a catalyst-based demo store and look to integrate our apps.

One of the first things I noticed is that once you have an item in your cart, every page becomes a cache miss. This seems a shame.

My current understanding of this is based on this from the vercel docs:

Next.js provides helpful functions you may need when fetching data in Server Components such as cookies and headers. These will cause the route to be dynamically rendered as they rely on request time information.

and this.

Good to know: cookies() is a Dynamic Function whose returned values cannot be known ahead of time. Using it in a layout or page will opt a route into dynamic rendering at request time.

When I look in the Header cart, I can see a request to cookies to get the cart ID so that the cart can be fetched server-side.

My question is: what would be the best practice approach to improve this?

1. Change the cart to a client component with suspense fallback for the default cart of no items
2. Move just the count badge to be its own client component
3. Some other approach that I've missed
4. Or, no Tom, this is actually by design 🙂

Thanks for any guidance!

[jorgemoya]

Hi @bobbyshaw!

First of all, thanks for the kind words! We're really excited for Catalyst and I'm glad you're diving deep into it! Feedback definitely welcomed.

In regards to your question, this has definitely been interesting for us to tackle and certainly a case for discussion. Short answer would be that this is actually by design, but I can try to provide a long answer to the best of my knowledge.

In reality this is a two part issue.

1. Vercel's Full Route Cache will only work when runtime is node, which is not clearly documented I believe. Since we want to use Edge, our approach was to identify if we need to dynamically render the route here, and if we don't, we redirect to a statically rendered page in which we provide static params for (example). This is what you notice as HIT and it's definitely a best case scenario. However, when we skip the static rendering and go back to Edge runtime and thus hit a MISS, there are other solutions at play (more below).
2. The reason why we believe this is not a major issue is because most requests are being cached by NextJS's Data Cache. Data Cache will store requests and prevent from hitting origin/data source on every render. So even though we get a MISS when running on Edge and/or having dynamic route, we're still getting a huge boost simply by using Data Cache which caches request. Note: Normally, any following requests after a dynamic requests (in this case no-store) wouldn't be cached, but our solution for this was to provide this configuration to force NextJS to force cache any requests after it. Combined with React's memoization of requests, we're getting a rich solution for these dynamic pages.

In conclusion, even though we do lose the Full Route Cache when we need dynamic routes, Data Cache will provide a huge boost in performance compared to a fully dynamic page.

[bobbyshaw]

Thanks for the detailed explanation @jorgemoya. I understand a bit more now!

[christensenep]

Hey @bobbyshaw, to add on to @jorgemoya's answer above regarding our caching strategies, I will add that for the cart specifically, we are considering doing an optimization like you are describing (making the cart a client component that hits a new api route, revalidates when appropriate, etc.) which would allow us to still serve fully static pages when a cart is populated, though there will remain other scenarios where we cannot. We're weighing a complexity/performance tradeoff there and your feedback that this would be valuable from your perspective certainly helps.

[bobbyshaw]

Thanks @christensenep. That's good to hear.

My initial concern was triggered by the sub-par response times in my setup. I found that even with Vercel KV configured I was getting an average homepage response time of ~800ms, but with an item in the cart this became ~1.5s.

I realised this isn't the experience on https://catalyst-demo.site/ and I've identified the cause as Cloudflare. Out of habit when setting up the CNAME, I'd left Cloudflare proxy as enabled rather than DNS enabled. I've now switched Cloudflare to DNS only which makes a lot more sense given what I've learnt about the use of edge runtime from @jorgemoya.

I'm now seeing ~200ms response time for the homepage with no cart and ~600ms response time with an item in my cart.

In my experience with monolith server-side applications with varnish in the mix, I've found the portion of traffic that had a cart to be not insignificant and so we had to look at edge-side includes or client-side implementations to maximise cache hit rates and performance.

If you have a moment more, I'd be interested to learn from your perspective on the trade-offs of moving the cart to a client component.

[christensenep]

Oh good, yeah, those response times sound about right for the default config w/ Vercel KV, although of course we're always looking to improve them and aren't resting on our laurels there.

Regarding trade-offs, we're just trying to be intentional about the complexity we add to Catalyst and make sure we're adding optimizations where they're important to people, so just hadn't prioritized this yet. Like I said, your feedback here is extremely valuable (frankly, even the fact that you noticed this so quickly was an exciting data point) so we'll likely take a look at exploring this.