Hello folks :wave: . Nice to meet you. We're just ...
# announcements
m
Hello folks 👋 . Nice to meet you. We're just planning out our growthbook setup and have some difficulty adapting the caching strategy for our content. Our cache sits in front of the application on the network level. Any change in growthbook would require flushing the cache and warming it up again, a costly operation. Is there any alternative to this? And thinking further: Is there a growthbook middleware(-concept) ?
f
Hello! Yeah, there are 2 general strategies for dealing with cached content. 1. Move tests to the client-side. Everyone gets the same cacheable HTML and Javascript, traffic split happens in the front-end 2. Run the A/B test in a middleware or CDN edge worker and route traffic to different cached pages depending on test variant
My answer above is specifically if you are using GrowthBook to run A/B experiments. If you are just using feature flags and just want a global on/off switch for features (i.e. you're not changing the feature value for specific users), then there's a 3rd option - use a shorter TTL on your cache or a stale-while-revalidate policy. Feature changes will gradually take effect on pages as the cache refreshes.
m
Thank you for your quick reply. 1. I am afraid this is not an option because of react's hydration mismatches, and, more critical, page load content layout shifts 2. This is most likely what we'll build, yes, though the cache cardinality could become a problem. Any ideas which reverse-proxy to build on top of? 3. Stale-while-revalidate it is. Just a TTL would to expose uncached content to search engines.
f
Are you using Next.js? If so, the built in middleware works well. Also, for front end, there wouldn't be any hydration mismatches if using our React SDK. You can have the server render the default feature values, then swap in the most up-to-date values in a useEffect hook on mount if it's different. Depending on what and where you are using it on a page, you might be able to use something like suspense to show a loading state until the feature is ready.
m
Yes, we're using nextjs. And yes, the middleware is usable but still, our cache needs to sit between growthbook and the renderer. Good to know hydration mismatches can be avoided. Re-shuffling the UI w/ useEffect though may still produce content layout shifts w/o any prior user interaction. Currently going for the growthbook injecting reverse-proxy in front of the cache.