Open source platform for stress free deployments, measured impact, and smarter decisions.

GrowthBook Users

I'm wondering if the Lambda@Edge solution might be a solution to some of our cache-related issues.

Primarily that we seem to be serving content to users from the cache, even when the change is being facilitated server-side, meaning they see the cached version and don't see the experiment edits right away, or worse, some users see it and others don't depending on when the page was invalidated last. In instances where there's functionality on the origin server that is relevant to the experiment and can't be stored in the flattened html that sits in the cache I'm wondering if the edge SDK and some hydration-centric solution might allow us to be more flexible with running experiments server-side (instead of client) but also benefit form the speed of the cache. Currently we're being forced to turn off the cache for experiments that require server-side functionality to deliver the new experience we're testing. When that's not a requirement we're essentially using JS on the client (and hence can all sit within the cached page) much the same way you might have done with a front-end testing tool using a stock standard JS snippet to handle everything.

The Edge could be a solution, but I'd like to know more about your current implementation. How are you integrating GB into your stack?

I assume this channel is for discussion on the Edge SDKs?

Hi Jesse, that's correct. Do you have a question about implementing the Edge SDK?

I guess my first question is whether the edge sdks are available on all plans?

Does it have all, if not most of the JS SDK functionality? I'm guessing it's a "lite" version in a way??

Hi <@U07FMR69EF5>, picking up here. The Edge SDKs are a full integration of the JavaScript SDK. we support Fastly Compute, Lambda@Edge, and Cloudflare Workers out of the box and provide instructions for other providers

Here is the <https://docs.growthbook.io/lib/edge/cloudflare|documentation> and a more <https://blog.growthbook.io/better-visual-editor-experiments/|deep dive>.

Thanks. I'll check the deep dive you've mentioned. Keen to determine if it be used in conjunction with feature testing

Apologies. I'm not an engineer, i'm just doing some initial investigation.

Hey <@U077LKXUEFQ> can you confirm this is at no extra cost to use for a Pro account? Also I'm going to get my platform team to investigate this from a network cost impact. Do you have any info you can point me at or share that would give me some indication of how this would affect our network pipelines that could drive up costs and how I might go about calculating that at a very top level?

Sorry for the delay. Yes, the Edge SDKs can be used on any plan. However, do note that they require additional engineering work and costs, depending on the platform you choose. For example, if you went with Fastly, you'd have to set up the Edge worker there and pay for usage.

I think the GrowthBook pricing is fairly predictable: <https://www.growthbook.io/pricing|https://www.growthbook.io/pricing>

Yes, I have setup edge worker. However, I have client side app Angular so I get variant page only if I access it directly by URL. If I navigate to experiment page inside application, I don't get variant page displayed. How can I combine edge worker with other setup?

Hello,
I have already setup Cloudflare Growthbook SDK and it works. However, I have a problem with caching.
My infra setup is: Cloudflare -&gt; Azure cache -&gt; FE server. Azure cache - caches pages by path and query param. But as I understand both ab test versions will go from edge worker to FE server as regular URL. So, the problem is that cache may return A version of the website when user should receive B version.
• Do you have any recommendations on caching while using Cloudflare edge worker?
• What URL does edge worker sends to FE server? Maybe it adds some query params?
• Is there any docs, how it works under the hood?
• Is there someone I could consult about how to use edge worker? 

Hi Deivydas, thank you for writing in and apologies for the delayed response here

I will now escalated this query to our Edge SME to review the above

Just a quick note that the Eng team is based in the PST timezone so we may not have a response on this until the end of the day when San Francisco wakes up, but this has been escalated and on our radar :pray:

Hi Deivydas, I'm a little confused by your infra description and how Cloudflare and Azure Cache are both being used.  Can you elaborate a little more?

And by Azure Cache, are you referring to their Redis service?  Or their Front Door CDN service?

Hi. Front door service. We have CF edge worker setup by Growthbook example and from there requests go through Azure Front Door Rules with cache enabled to FE Server(Node Js).

<https://learn.microsoft.com/en-us/azure/frontdoor/front-door-rules-engine-actions?tabs=portal&amp;pivots=front-door-standard-premium#examples>

Ok, thanks.  That makes sense.  I think that setup should work fine.

If you use Visual Editor experiments in GrowthBook, the Edge SDK can apply the changes to the HTML before it's returned to the browser.  Azure and your FE don't need to do anything special.

If you use URL Redirect experiments, the Edge SDK rewrites the URL before it forwards the request to Azure.  So your users will only see `/a` in their browser for example, but Azure will get a request for either `/a` or `/b` and just needs to respond like it normally would for the different URLs.

Thanks, one more question. I have added visual editor experiment with edge worker. And when I go to the experiment page directly by a URL in a browser, it works as expected. But when I open website's homepage and navigate to my experiment page by menu, it has some flickering. My app is Angular and I have added GB HTML Script Tag SDK. I need to solve this flickering problem, do you have any idea why it is happening and how can I solve it?

The best bet will be to leverage the Edge SDK for flicker-less visual testing instead of the HTML SDK!

However, as an alternative, the general approach would be to initially hide the elements you're testing using CSS, and then use JavaScript to reveal them once the user has been assigned a variation.

You can set the CSS and JS code using the Visual Editor.

Here is a general example for the CSS snippet:
```/­­* CSS ­­*/
.your-element-class {
  visibility: hidden;
}```
And a general example for the JS snippet:

```// This is a placeholder function. Replace it with the actual function from GrowthBook SDK
function onExperimentLoaded() {
  var element = document.querySelector('.your-element-class');
  element.style.visibility = 'visible';
}

// Call the function when the user is assigned a variation
onExperimentLoaded();```

While this method technically prevents flickering, it can cause a delay in loading the page.

It's also important to handle the case where the experiment fails to load, to prevent the page from staying hidden indefinitely.

image.png

Hi, thank you for your previous replies.

I am implementing custom edge Cloudflare worker which will add features' as cookies to request response. Based on this cookies, Front-end will decide if feature should be shown.
I would be very glad if you could verify a few things about how JS lib is working in edge worker(please look at the code I provided).
1. loc 21. Is it ok if I create identifier ID myself if it doesn't exist?
2. loc 41. Does it make a network call? (I have setup KV store)
3. loc 45. Will this use identifierValue to make a decision? does it make a network call?
4. Do you have any suggestions or improvements for this flow?
Thanks in advance! :pray:

index.js

Hi Deivydas, I will escalate this to the team and get back to you shortly :pray:

Hi Deivydas, sorry we have not received an update on this yet. Let me message the team internally and get back to you :pray:

Sorry for the delay.  To answer your questions:
1. Yes, you can create a random identifier if it's missing.  I see you're setting it as a cookie at the end of the request, so that's good.
2. getFeatures is not async and does not make a network call
3. isOn is also not async and does not make a network call
4. If you're planning on running A/B tests, you will also need to track which variation each user sees.  This is done by specifying a `trackingCallback` function in the gbContext.  If you do this, you also might run into problems since you are evaluating all feature flags on every request, even if they aren't being used in the front-end.

Thank you for your feedback.
4. Because our Front-End app is SPA (Angular) we send `trackingCallback` in FE client side part. We can't do this in CF worker because we are not sure if user navigates to experiment page.

I have an issue with mutually exclusive experiments in my current setup. Right now, the code checks all active features and sets each feature's cookie to either 'on' (1) or 'off' (0). However, when features are mutually exclusive, a user should only receive cookies for the features they're actually assigned to, not all features.

Could you recommend a better approach? I believe we should replace the `getFeatures` method with something more appropriate. I'd prefer to follow recommended best practices rather than create a custom solution.

I found that we can detect features with active experiments by using the <https://docs.growthbook.io/lib/js#evalfeature|evalFeature(key)> method and examining its result's source property.
I manually exclude features where source = "defaultValue" to have features only with active experiments.
```    let featureCookies = [];
    for (const [key, feature] of Object.entries(features)) {
      const result = growthbook.evalFeature(key);
      console.log("feature", result);
      if (result.source !== 'defaultValue') { // we want to return cookies only with active experiments
        featureCookies.push({ key: key, value: result.value });
      }
    }```
Would you share your insights about this approach?

Hi Deivydas, apologies for the delayed response here. Are you still facing a blocker with this?

Well, actually it is not a blocker anymore, today we released it into production. I have issued another blocker is that vitest tests doesn't work with cloudflare edge worker libraries. There could be an example github repository created with running tests.
<https://growthbookusers.slack.com/archives/C01T6Q1SVFV/p1732605260670289|Here's this issue.>

Hi Deivydas, I can see that Bryce has answered this on the original thread- he's our Edge SDK expert and best point of contact to answer your query. He's out for the rest of the week for Thanksgiving but he'll be back next week :pray::skin-tone-5:

Sorry Deivydas, this is now on our radar and thank you for the nudge on this :pray:

Hi there,
Did someone have already implemented Lambda@Edge SDK ? I am struggling to make it work. A bit of help would be appreciate :slightly_smiling_face:

I put together a starter kit. Not fully tested but hopefully enough to get you pointed in the right direction:
<https://github.com/growthbook/sample-growthbook-lambda-edge>

Hello <@U04D18P8B5Z>,
Thank you so much for the starter kit.
I just wanted to be sure that the lambda should be connected to `origin-request` .
I checked the source code and handleRequest fetches the page regarding the experiment.
Am I right ?

Okay, so I made it work !
I think there are two bugs in the package that lead to a 503 error:
• The cookie parsing function `getCookie` in `helper.js` may throw an exception - for loop on undefined. 
• It seems that `statusCode` property returned within the response should be called `status` instead.
I also had to increase the timeout duration of the lambda function which was originally set to 3s.

We actually intended the lambda to operate at the `viewer-request` level. It should work at the origin level though if you have proper per-user caching, cache invalidation (you won't want to serve stale results for long if your GB `api/features` payload changes, for example) and/or a short TTL.

Thanks for pointing out the hiccups. I want to make sure I fully understand what you're encountering.
1. Noticed a typo (`cookies` vs `cookie`, sorry!), but will also add optional chaining for accessor safety.
2. Where are you seeing `statusCode`? I did notice a few problems with response `status` (not always set).
I will push a new version of the package based on this feedback, but please let me know if I missed anything.
edit: ver `0.0.9` is now available

I already tried to make it work on `viewer-request` but I encountered 3 issues:
• when importing the edge-lambda package, my lambda bundle exceeds the size limit of 1 MB since the edge-lambda package weighs 1.1 MB. I managed to minify it to be < 1 MB
• I reached the timeout for viewer-request but I didn't know back then that I could increase it from 3 seconds to 5 seconds which should fix the issue.
I'll try again with those settings and the new package version. I think all those instructions should be added to the tutorial, debugging AWS lambda errors could be such a pain.

About the status code, my guess was the wrong property was set. But you're right, the error probably came from a missing status code and not a misspelling.

Thank you for your package and the new version, I struggled a bit but it saved me a lot of time :pray:

But I was wondering, regardless you want to return directly the response or not, you fetch the redirect URL, right ? Wouldn't it be more efficient to return a 307 from the `viewer-request` ? Or you need to fetch the redirect URL to inject growthbook and trigger the `experiment_viewed` with the right variation ?

If you're still having trouble with the bundle size, try out the <https://github.com/growthbook/sample-growthbook-lambda-edge|sample project> if you haven't already. For me the final unzipped .js file is only 654KB. Rollup and tree shaking.

If you're having issues with latency, I'd suggest looking into GB API payload caching if you haven't already. Rather than fetch the API payload on every request, you can cache the payload in something like DynamoDB and use GB's SDK Webhooks to push updates to Dynamo when things change.

As for a 302/307, there are several reasons that is sub-optimal in many cases. It forces a double fetch on the user side which (a) biases against that variation and (b) increases tracking call dropoff (SRM issues). Also like you mentioned, if the Edge SDK is injecting the &lt;script&gt; SDK and/or deferred tracking calls (versus tracking on-edge), then there's no real way to pass the requisite information to a 302/307. And finally, we support hybrid experiments: combinations of visual editor tests and redirects, which are much more efficient if they happen "behind the scenes" on edge. There are some cases though where a 302/307 might be more efficient though, in which case you could just use our standard JS SDK and do your own tracking and redirection.

Hello !
I was able to deploy the lambda on the `viewer-request` using your repo and increasing the timeout to 5s ! :tada:
Thank you for your help and this little chat :slightly_smiling_face:

Very welcome, glad it's all working! Please let me know if anything else comes up :simple_smile:

Hey ! It's me again. 
I was planning to perform a visual editing experiment on edge for my wordpress. I just made a variation with a different wording for a CTA.
It seems that this experiment breaks my UI or at least my CSS.

Even if I am not modifying the UI but only injecting some JS console.log through a visual experiment, the UI / CSS gets broken :thinking_face:

If you'd like to DM me the website and url to your growthbook experiment (assuming you are not using GB self-hosted), I can have a look.

Hello everybody :slightly_smiling_face: :wave: <@U0803M6H7PG>

Hey Specialists! I'm currently experimenting with edge-cloudflare and I'm running into some questions and issues. Hopefully someone can shed some light on this.

Just as some background, for our experiments we use Featureflagging and a custom build GB script. We do not use the visual editor or use redirect variants.

To implement the CF worker, a PROXY_TARGET needs to be set.

Questions:

1. What is this proxy target for? The intention is to use a wildcard CF route for the worker - which means the worker should run on all paths on the site. So what is the recommended value here? 
2. I'm noticing that the growthbook script is injected not only on HTML pages - but also inside js scripts - which breaks the site. What am I missing here?

Hi, I'm trying to get a connection between our self hosted GrowthBook app in ECS Fargate and the basic Lambda Edge turnkey app. I am using "viewer-request" for the Lambda association but the browser responds HTTP 502 - The function tried to add a blacklisted header. I think it's the *connection* header. Any idea what I can do to fix this? Thanks.

The growthbook app sees a connection to Lambda Edge - just the app to be A/B tested gives the 502

Just testing now but it seems `FORWARD_PROXY_HEADERS: false` may have solved this

<@U08QS98P73M> We're experimenting w growthbook and I think I've run into the same issue with the 502. When I added growthbook to the edge, all the requests were timing out 3s and the browser was showing 502. Were you seeing timeouts?

Hi Nate, seems like a long time ago now but I did get it working in the end. I can't quite remember the specifics of how I got it to work off hand. Have you managed to fix your issue?