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

GIVE DOCS FEEDBACK

Getting started with SDKs

Read time: 3 minutes
Last edited: Feb 10, 2024

Overview

This topic explains the prerequisites you must consider when you're setting up a LaunchDarkly SDK for the first time.

Newer versions of LaunchDarkly SDKs replace 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."

Creating contexts and evaluating flags based on them is supported in the latest major versions of most of our SDKs. For these SDKs, the code samples on this page include the two most recent versions.

Prerequisites

Regardless of which SDK you use, everyone who integrates LaunchDarkly with their code must consider the following prerequisites. Making decisions about the items listed below will help you use feature flags in a way that makes sense for your use case, customers, security considerations, and existing network architecture.

Consider the following factors when you're starting to integrate LaunchDarkly SDKs with your code:

  1. Determine what kind of SDK you need to use.
    • Depending on your use case, you may need a server-side, client-side, mobile, or edge SDK.
    • You only need one SDK per application or service. You can use multiple SDKs if your product is comprised of applications or services written in multiple languages.
    • You do not need multiple SDKs to support front-end and back-end behavior, but we support this configuration if it works best for you.
    • All of our SDKs are thread-safe, ensuring consistent behavior from an SDK when you use it in multiple threads.
    • To learn more about SDKs, read Client-side, server-side, and edge SDKs.
  2. Identify the language you want to use. In some cases, we support multiple SDKs for a language. To learn more, read Available SDKs. We may also provide a sample application in your preferred language or framework, even if we don't have a dedicated SDK. To learn more, read Sample applications.
  3. Confirm that your tech stack is compatible with the SDK you want to use.
    • More information about each SDK's dependencies is available in the documentation for the specific SDK, and in the SDK's README in GitHub.
    • LaunchDarkly uses the SLSA framework to help developers ensure the authenticity and build integrity of published SDK packages. More information is available in the SDK's README in GitHub.
  4. (Optional) Determine if you need to use the Relay Proxy. To learn more, read The Relay Proxy.

Implementation guidelines for LaunchDarkly SDKs

Here are some basic guidelines for implementing LaunchDarkly SDKs:

Consider your SDK use case

The SDK types have different security considerations as well as some behavioral and architectural differences. They handle flag evaluations differently, utilize different kinds of SDK keys, and support different languages.

To learn more, read Client-side, server-side, and edge SDKs.

Plan for a large initial payload from the streaming endpoint

The initial payload contains all the targeting rules for the environment associated with the provided SDK key. If you target a large number of individual contexts, have a very large number of flags, or have large numbers of extremely complicated rules, then this can increase the initial payload size. Configure any relevant timeout options to anticipate a large initial load. This helps prevent the SDK from timing out.

Ensure you have a reliable network connection for first-time initialization

The SDK will time out if it cannot get a network connection to LaunchDarkly. Failure to connect is a recoverable error, so the SDK will keep trying to reconnect, but a timeout could happen in the middle of an attempt. If the SDK times out during a first-time initialization, it will serve the flag values you defined in your application code until it can connect to LaunchDarkly.

Implement SDKs in a singleton pattern

Your SDK should only initialize once statically, and that instance should be the exclusive instance you use for a given LaunchDarkly project. When you create multiple SDK instances, previous instances may leak into memory and stay active beyond their useful lifespan.

When you have enough of these instances running, they can cause bottlenecks in the connection to the streaming endpoint.