Good day everyone, I'd appreciate some clarifications/support to properly implement a hybrid solution with a CloudFront cache layer (I've read the GB Lambda Edge docs). I'm very familiar with Edge functions, so my question below is really behavior/cache related 🙂 Versions

"next": "^15.1.4",
  "react": "19.0.0",
  "@growthbook/growthbook-react": "^1.4.1",

Application The application is a SPA Webshop available over multiple TLD, where initial page load is always rendered by an SSR origin with a wide caching policy (auth, domain, QS cache keys). Growthbook Principally uses Feature flags to determine A/B display. With the above case, I'm wondering exactly what the edge function does or requires to function correctly with feature flags to ensure the correct A/B is served & that cache hit rates don't go in the gutter. I'm looping in the responsible developer ( @handsome-boots-98446 ) as I'm backend/infra responsible. Edit: Realized I wasn't clear, a client-side only implementation is already live & some initial implementation done on the SSR server.

Our edge app does not leverage CloudFront directly - and in fact there is very limited support for non-user-requests given what the edge app does (mutates the DOM, fetches/buffers "redirect" urls and serves them). You may be better served by manually implementing the JavaScript SDK into your function if you require tighter integration with CloudFront

thanks @happy-autumn-40938, that does well to answer. So now I've got a followup for you as we have an implementation plan for full page server side renders of 1..N feature flags. What I'd like to know is a bit about the behavior of the growthbook SDK. Lets say a cached rendered page is served by our CDN that contains some active experiments. Will the client side pick that up & fire requests to GB for analytics purposes?

If the client side instruments the experiments, then everything should work properly. If you're doing testing on edge, then you need to make sure that either: 1. your edge function can fire your tracking callback (experiment exposure event), or 2. you inject enough information onto the DOM to allow the client side to pick up the deferred tracking call. The SDK has a notion of get/setDeferredTrackingCalls to help with this

@handsome-boots-98446 sounds like a decision for you, it'd simplify on my side that I wouldn't need to cover all the cases on cache hit to fire these calls on the edge