Skip to main content

Cloudflare Workers Edge App & SDK
beta

Overview​

GrowthBook currently supports two levels of integration with most edge workers, including Cloudflare:

  1. Our turnkey Edge App

    • Automatically run server-side or hybrid Visual Experiments without redraw flicker.
    • Automatically run server-side or hybrid URL Redirect Experiments without flicker or delay.
    • Optionally inject the JavaScript SDK with hydrated payload, allowing the front-end to pick up where the edge left off without any extra network requests. We use an enhanced version of our HTML Script Tag for this purpose.

  2. Support for edge apps using our JavaScript SDK

    • Enhanced support and examples for using our JavaScript SDK in an edge environment

Regardless of your use case, our Cloudflare integration makes easy to synchronize feature and experiment values between GrowthBook and Cloudflare's KV store. This eliminates the network request to the GrowthBook API, unlocking blazingly fast edge-side and client-side SDK performance.

References​

  • Our Cloudflare Workers SDK repository, which supports the above use cases, is here
  • A turnkey implementation of the Edge App (compatible with Wrangler) is here
  • You may find it useful to review our JavaScript SDK. Many of the concepts which apply to both on-edge and injected frontend SDKs are based on our JS SDK.

Worker Configuration​

tip

This tutorial assumes some familiarity with building and deploying Cloudflare Worker applications. You can quickly get up to speed by following the Cloudflare Workers Getting Started guide.

You may either use our turnkey Edge App for Cloudflare Workers or build your own app from scratch using our JavaScript and Cloudflare SDKs.

Turnkey Edge App​

Our Edge App runs as a smart proxy layer between your application and your end users. In absence of Visual or URL Redirect experiments, the Edge App will simply proxy the user request to your site and return the response, optionally injecting a fully-bootstrapped JavaScript SDK onto the rendered HTML page. If the request URL matches an Visual or URL Redirect experiment and the targeting conditions are satisfied, the Edge App may also perform one or more URL redirects behind the scenes (the public-facing URL does not change) and/or mutate the DOM for Visual Experiments.

URL Redirects on edge

The Edge App defaults to running URL Redirect Experiments in the browser only. This is because edge redirects load a separate page's content without altering the URL. After the redirect, some sites may experience problems with loading assets or endpoints with relative paths.

You can enable URL Redirects on edge by setting environment variable RUN_URL_REDIRECT_EXPERIMENTS (see below).

Setting up our turnkey Edge App is simple. Assuming that you have a basic Worker application set up, simply install the SDK and implement our custom request handler. Or if you prefer, you may pull down our fully-functional example implementation and follow along.

Install the SDK​

npm install --save @growthbook/edge-cloudflare

Implement the Edge App request handler​

A basic implementation of our Edge App only requires a few lines of code:

import { handleRequest } from "@growthbook/edge-cloudflare";

export default {
  fetch: async function (request, env, ctx) {
    return await handleRequest(request, env);
  },
};

Configure the Edge App​

Use a combination of environment variables and optional runtime configuration to add required fields and to customize the Edge App behavior.

Environment variables​

Edit your wrangler.toml file and, at minimum, add these required fields:

[vars]
PROXY_TARGET="https://internal.mysite.io"  # The non-edge URL to your website
GROWTHBOOK_API_HOST="https://cdn.growthbook.io"
GROWTHBOOK_CLIENT_KEY="sdk-abc123"
GROWTHBOOK_DECRYPTION_KEY="key_abc123"  # Only include for encrypted SDK Connections

You may want to further customize the app. Here is a list of common customization variables:

# Disable or change the rendering behavior of Visual Experiments:
# ==========
RUN_VISUAL_EDITOR_EXPERIMENTS="everywhere"|"edge"|"browser"|"skip"  # default: "everywhere"

# URL Redirect Experiments are disabled on edge by default. Because the URL does not change, some sites
# may experience problems with loading assets or endpoints with relative paths:
# ==========
RUN_URL_REDIRECT_EXPERIMENTS="everywhere"|"edge"|"browser"|"skip"  # default: "browser"
RUN_CROSS_ORIGIN_URL_REDIRECT_EXPERIMENTS="everywhere"|"edge"|"browser"|"skip"  # default: "browser"
# Mutate browser URL via window.history.replaceState() to reflect the new URL:
INJECT_REDIRECT_URL_SCRIPT="true"  # default "true".

# Do not inject a bootstrapped JavaScript SDK onto the page:
# ==========
DISABLE_INJECTIONS="true"  # default "false"


# Customize the edge or injected browser SDK behavior:
# ==========
ENABLE_STREAMING="true"  # default "false". Streaming SSE updates on browser.
ENABLE_STICKY_BUCKETING="true"  # default "false". Use cookie-based sticky bucketing on edge and browser.

Runtime configuration​

You may want to provide context to your edge app at runtime rather than using environment variables. For example, if you have additional targeting attributes available, you may inject them by modifying your request handler code:

import { handleRequest } from "@growthbook/edge-cloudflare";
import { parse } from "cookie";

export default {
  fetch: async function (request, env, ctx) {
    const cookie = parse(request.headers.get("Cookie") || "");
    const config = {
      attributes: {
        userType: cookie["userId"] ? "logged in" : "anonymous"
      }
    };
    return await handleRequest(request, env, config);
  },
};

More customization options​

For a full list of customizations, view our vendor-agnostic Edge Utility repository .

Set up a Payload Cache​

You can configure GrowthBook payload caching by using a Cloudflare KV store. This eliminates network requests from your edge to GrowthBook which speeds up page delivery while reducing network costs.

Our Cloudflare Edge App will automatically use either webhook-based or just-in-time payload caching (or both) depending on how you've set up your KV namespaces, bindings, and SDK Webhooks.

More information about setting up your payload cache can be found in the Payload Caching with Cloudflare KV Store doc section below.

Tracking Experiment Views​

Running A/B tests requires a tracking callback. Our turnkey Edge App defaults to using built-in front-end tracking. The tracking call automatically integrates with Segment.io, GA4, and Google Tag Manager by using the mechanism outlined in our HTML Script Tag. In order to do this, the app keeps track of tracking calls triggered on edge and injects them into the front-end SDK to be automatically triggered on page load.

You may wish to either customize front-end tracking or switch to edge tracking (or use both concurrently if running hybrid edge + front-end experiments).

Why might you be interested in tracking on edge? Tracking on an edge or backend environment allows you to ensure the callback is fired before any differentiation across variations, eliminating experimental bias. While not eliminating this risk, the default injected front-end tracking introduced by our Edge App does reduce this risk relative to solely using a front-end SDK.

To change the front-end tracking callback, set the GROWTHBOOK_TRACKING_CALLBACK to your custom tracking JS code:

# todo: replace with your own tracking library
GROWTHBOOK_TRACKING_CALLBACK="(experiment, results) => { console.log('browser tracking callback', {experiment, results}); }"

To track on edge, you must inject your own tracking callback into the edge request handler code. Any experiments that run on edge will use the edge tracking callback and not the front-end callback (hybrid edge + front-end experiments being an exception):

import { handleRequest } from "@growthbook/edge-cloudflare";

export default {
  fetch: async function (request, env, ctx) {
    const config = {
      edgeTrackingCallback: (experiment, results) => {
        // todo: replace with your tracking library
        console.log('edge tracking callback', {experiment, results});
      }
    };
    return await handleRequest(request, env, config);
  },
};

Targeting Attributes​

The following targeting attributes are set automatically by the Edge App.

  • id - creates a long-lived gbuuid cookie if it doesn't exist already
  • url
  • path
  • host
  • query
  • pageTitle
  • deviceType - either mobile or desktop
  • browser - one of chrome, edge, firefox, safari, or unknown
  • utmSource
  • utmMedium
  • utmCampaign
  • utmTerm
  • utmContent

You can customize both the primary identifier name (id) and cookie name (gbuuid) by setting the UUID_KEY and UUID_COOKIE_NAME environment variables respectively.

As shown in the runtime configuration section above, you can also pass custom attributes via runtime config. You can also skip automatic attribute generation and rely solely on custom attributes by setting the environment variable SKIP_AUTO_ATTRIBUTES="true".

Routing​

By default, the Edge App will process all GET requests (other HTTP verbs are proxied through without running through our app logic).

It is generally preferable to configure your routing rules outside of our Edge App. For instance, you may only want to invoke the Edge App at https://yourdomain.io/landing-page. You can configure Cloudflare routing by following the Cloudflare Workers Routes documentation.

There may be situations when you will need to provide finer-grained routing / URL targeting rules within our Edge App. You will need to include a JSON encoded string of route rules in your ROUTES environment variable.

For instance, you may want to do a proxy pass-through (do not process) for mysite.io/account/* or mysite.io/settings/*. Your routes may look like this:

ROUTES='[{ "pattern":"mysite.io/account/*", "behavior":"proxy" }, { "pattern":"mysite.io/settings/*", "behavior":"proxy" }]'

A route uses the following interface, with many of the properties being optional:

{
  pattern: string;
  type?: "regex" | "simple";  // default: "simple"
  behavior?: "intercept" | "proxy" | "error";  // default: "intercept"
  includeFileExtensions?: boolean;  // Include requests to filenames like "*.jpg". default: false (pass-through).
  statusCode?: number; // Alter the status code (default is 404 when using "error")
  body?: string; // Alter the body (for setting an error message body)
}

When multiple routes are included in your ROUTES array, only the first match is used.

By default, the Edge App will persist a random unique identifier in a first-party cookie named gbuuid. Its purpose is to provide a consistent user experience to your visitors by preventing them from being re-bucketed into different A/B test variations. It follows the same mechanism as discussed in our HTML Script Tag docs.

If you must delay persisting the gbuuid cookie until a user consents, you can set the environment variable NO_AUTO_COOKIES="true".

This will still generate a UUID for the user, but will not persist it. That means, if the user refreshes the page, they will have a new random UUID generated.environment

You have the option to manually persist this cookie at any time, for example when a user grants consent on your cookie banner. All you need to do is fire this custom event from javascript on the rendered page:

document.dispatchEvent(new CustomEvent("growthbookpersist"));
note

If you are using Sticky Bucketing, a persistent sticky bucket assignments cookie will automatically be generated. If you require user permission before writing cookies, you should:

  • Either do not enable Sticky Bucketing on edge (do not use ENABLE_STICKY_BUCKETING)
  • Or only enable Sticky Bucketing per each user via runtime configuration. (only pass config.enableStickyBucketing: true if user has consented — identifiable by checking for presence of the gbuuid cookie).

Manual SDK Integration on Edge​

You may be interested in building your own edge application using the GrowthBook SDK and not using our turnkey Edge App. Or you may want to do custom feature flagging on specific routes while running our Edge App on other routes.

To use the GrowthBook on edge, simply include our standard JavaScript SDK (@growthbook/growthbook NPM package).

In our @growthbook/edge-cloudflare NPM package, we export a few Cloudflare-specific utility functions to simplify SDK payload caching (we discuss payload caching strategies in the subsequent doc section).

import { GrowthBook, setPolyfills } from "@growthbook/growthbook";
import { getPayloadFromKV, getKVLocalStoragePolyfill } from "@growthbook/edge-cloudflare";

export default {
  async fetch(request) {
    // 1. Init the GrowthBook SDK and choose an optional caching strategy

    // A. Use the KV as a managed payload store to eliminate SDK requests to the GrowthBook API entirely.
    // Requires setting up an SDK Webhook.
    const payload = await getPayloadFromKV(env);
    const growthbook = new GrowthBook(gbContext);
    await growthbook.init({ payload: payload });

    // B. Or provide a KV cache layer so that the GrowthBook SDK doesn't need to make as many requests
    // to the GrowthBook API. No SDK Webhook needed.
    const localStoragePolyfill = getKVLocalStoragePolyfill(env);
    setPolyfills({ localStorage: localStoragePolyfill });
    await growthbook.init();

    // 2. Start feature flagging
    if (growthbook.isOn("my-feature")) {
      return new Response("<h1>foo</h1>");
    }
    return new Response("<h1>bar</h1>");
  }
}

Payload Caching with Cloudflare KV Store​

By default, the Edge App will make a network request to the GrowthBook API on each user request in order to fetch the current feature and experiment values. This is a blocking call that delays page delivery. There is an in-memory short-lived cache layer on this call, but it won't always protect you.

Convenient solutions this problem are realized through Cloudflare KV , an on-edge key-val store which we can leverage for persistent payload caching. There are 2 levels of KV integration available:

  1. You can either completely eliminate the blocking call to the GrowthBook API by implementing a GrowthBook-to-Cloudflare-KV push model via SDK Webhooks.
  2. Alternatively, you can eliminate most of these network requests by using Cloudflare KV as a just-in-time payload cache.

You can also use either of these strategies in your own manual SDK integration via the getPayloadFromKV and getKVLocalStoragePolyfill utility functions.

Configuring the KV store​

Create a Cloudflare KV namespace for your worker to interface with. You can do this either using the Cloudflare dashboard or via Wrangler commands. By default, the GrowthBook Edge App and KV utility functions use the following KV namespaces; you only need to choose one, not both, depending on your desired level of integration:

  1. KV stored payloads: KV_GB_PAYLOAD
  2. KV payload cache: KV_GB_CACHE

For KV stored payloads (1), we also assume a KV key of "gb_payload". You will likely not need to modify this, but for manual implementations both the namespace and key can be specified in the utility functions.

You must also create a KV binding so that your Cloudflare Worker can access the KV namespace. Edit your wrangler.toml file to add the binding:

# You probably do not need both bindings:
kv_namespaces = [
  { binding = "KV_GB_PAYLOAD", id = "abcdefg1234567" },
  { binding = "KV_GB_CACHE", id = "qwertyuiop12345" }
]

[vars]
...

Configuring a SDK Webhook​

For KV stored payloads (1), we eliminate network requests from edge to GrowthBook by using a GrowthBook SDK Webhook to push the SDK payload to the KV store on change.

  1. Create an SDK Webhook on the same SDK Connection that you are using for edge integration. You do not need to worry about the receiving end of the webhook (verifying GrowthBook signatures, etc).
  2. Select Cloudflare KV as the Webhook Type and fill out the following fields:
    • Account ID
    • Namespace ID
    • Key
    • API Token

Now whenever feature and experiment values change, your Cloudflare worker will have immediate access to the latest values. You can also test the webhook by using the "Test Webhook" button on the SDK Connection page.

Under the hood, the webhook is being configured with the following properties. If you need to change any of these settings for any reason, you can always edit the webhook.

  • Endpoint URL is being set to 
    https://api.cloudflare.com/client/v4/accounts/{accountId}/storage/kv/namespaces/{namespaceId}/values/{key}
  • Method is being set to PUT
  • An Authorization Header is being added with your API Token
  • The Payload format is being set to SDK Payload only