No results for ""
EXPAND ALL
  • Home
  • API docs

GIVE DOCS FEEDBACK

Cloudflare SDK reference

Read time: 5 minutes
Last edited: Feb 26, 2024
Version 2 of the Cloudflare SDK replaces users with contexts

A context is a generalized way of referring to the people, services, machines, or other resources that encounter feature flags in your product. Contexts replace another data object in LaunchDarkly: "users."

Code samples on this page are from the two most recent SDK versions where they differ. To learn more about upgrading, read Cloudflare 1.x to 2.0 migration guide and Best practices for upgrading users to contexts.

Overview

This topic documents how to get started with the Cloudflare SDK, and links to reference information on all of the supported features.

SDK quick links

LaunchDarkly's SDKs are open source. In addition to this reference guide, we provide source, API reference documentation, and sample applications:

ResourceLocation
SDK API documentationSDK API docs
GitHub repositoryjs-core/packages/sdk/cloudflare
Sample applicationExample app
Published modulenpm

The Cloudflare SDK is designed to be used with one of the LaunchDarkly client-side SDKs as follows:

  • The Cloudflare SDK gets all flags at the edge for a given context, and bootstraps them onto a cached payload
  • The client-side SDK initializes the bootstrapped payload
  • The client-side SDK evaluates the flags and sends events back to LaunchDarkly

If you are using Cloudflare SDK version 2.3.0 or later, then the Cloudflare SDK can send events back to LaunchDarkly directly. Using a client-side SDK is not necessary. You do need to configure the SDK to enable sending events. To learn more, read Configuration.

This SDK requires LaunchDarkly's Cloudflare integration

Configure the Cloudflare integration to use this SDK successfully. To learn more, read Cloudflare.

The Cloudflare integration is available to customers on an Enterprise plan. To learn more, read about our pricing. To upgrade your plan, contact Sales.

For use in Cloudflare Workers only

This SDK is intended only for use in multi-user Cloudflare Workers. Choose one of the other JavaScript-based SDKs for browser, server, or mobile environments.


Client-side browser environments:

Non-browser environments:

To learn more about LaunchDarkly's different SDK types, read Client-side, server-side, and edge SDKs.

Daemon mode

The Cloudflare SDK operates in daemon mode using the Cloudflare KV as a persistent feature store without connecting to LaunchDarkly. To learn more, read Persistent data stores.

If you are using Cloudflare SDK version 2.3.0 or later, then the Cloudflare SDK does send events back to LaunchDarkly if you configure it to do so. To learn more, read Configuration.

Getting started

After you complete the Getting Started process, follow these instructions to start using the LaunchDarkly SDK in your Cloudflare Worker.

First, install the LaunchDarkly SDK as a dependency in your application using your application's dependency manager.

Here's how:

yarn add @launchdarkly/cloudflare-server-sdk

Then turn on the Node.js compatibility flag in your wrangler.toml to allow the SDK to use node:events. Specify a build command in your wrangler.toml to use a bundler. Using a bundler to build your edge worker is recommended by Cloudflare.

compatibility_flags = [ "nodejs_compat" ]
[build]
command = "node build.js"

Next, import the LaunchDarkly client in your application code:

import { init } from '@launchdarkly/cloudflare-server-sdk';
The Cloudflare SDK uses a client-side ID

The Cloudflare SDK uses a client-side ID to associate the LaunchDarkly environment with the CDN integration. Your environment's client-side ID is available in the Projects tab of your Account settings page. To learn more about key types, read Keys.

After you install and import the SDK, create an instance of LDClient. Specify your client-side ID and Cloudflare KV namespace here. The client-side ID is only used to query the KV namespace, not to connect with LaunchDarkly servers.

Here's how:

const client = init('client-side-id-123abc', env.LD_KV);
await client.waitForInitialization();

If you are using the Cloudflare SDK version 2.3.0 or later, you can optionally configure sending events during initialization. This enables Experimentation use cases. To learn more, read Experimentation events.

Here's how:

const client = init('client-side-id-123abc', env.LD_KV, { sendEvents: true });
await client.waitForInitialization();

Await the waitForInitialization function after you initialize the client. When waitForInitialization is resolved the client can serve feature flags.

Using client, you can check which variation a particular context will receive for a given feature flag. In your Cloudflare Worker application, place the client.variation code so that it is invoked as needed.

Here is an example:

const context = {
"kind": 'user',
"key": 'user-key-123abc',
"name": 'Sandy'
};
const flagValue = await client.variation('flag-key-123abc', context, false);

Example Worker

This is an example Cloudflare Worker application that initializes the ldClient and evaluates a feature flag for a context.

import { init } from '@launchdarkly/cloudflare-server-sdk';
export default {
async fetch(request: Request, env: Bindings): Promise<Response> {
const context = { kind: 'user', key: 'test-user-key-1' };
// init the ldClient, wait and finally evaluate
const client = init('client-side-id-123abc', env.LD_KV);
await client.waitForInitialization();
const flagValue = await client.variation('flag-key', context, false);
return new Response(`${flagValue}`);
},
};

Read the full example in GitHub.

Promises and async

All asynchronous SDK methods that return a Promise are compatible with then/catch or async/await. You can use either.

Shut down the client

If you send events, you must flush those events before your worker exits to ensure that they are sent back to LaunchDarkly. To learn more, read Flushing events.

Shut down the client when your application terminates. To learn more, read Shutting down.

Supported features