LaunchDarkly Developer Documentation

Get started in under 30 minutes.
LaunchDarkly provides feature flags as a service for Java · Python · Ruby · Go · Node.js · PHP · .NET. Control feature launches -- who sees what and when -- without multiple code deploys. Easy dashboard for phased rollouts, targeting and segmenting.
Need more help? write us at support@launchdarkly.com

Get Started    Documentation

Client-side and server-side SDKs

Overview

This topic explains the differences between LaunchDarkly's client- and server-side SDKs and helps you determine which type of SDK to use.

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.

Understanding the different types of SDKs

It is important to understand the two types of SDKs we support. The different types of SDKs impact critical implementation details and use case.

All of our SDKs are one of these two categories:

  • client-side
  • server-side

Client-side SDKs include mobile SDKs

Our SDKs primarily for mobile devices, known as our "mobile SDKs", are categorized as client-side SDKs since, like our client-side SDKs, most mobile applications have a single-user context. This includes our Android, iOS, React Native and Xamarin SDKs. Each of these SDKs also has some mobile-specific functionality.

To learn more, read Functional Differences.

The table below summarizes the differences between client- and server-side SDKs:

SDK Type
Details

Client-side

  • These SDKs are designed for single-user desktop, mobile, and embedded applications.
  • These SDKs are intended to be used in a potentially less secure environment, such as a personal computer or mobile device.
  • These SDKs include mobile SDKs.

Server-side

  • These SDKs are designed for multi-user systems.
  • These SDKs are intended to be used in a trusted environment, such as inside a corporate network or on a web server.

Functional differences between SDKs

LaunchDarkly attempts to keep all SDKs at feature parity with each other. Even so, slight feature differences exist between server-side, client-side, and mobile SDKs.

Persistent feature store integrations

By default, our SDKs store transmitted data in in-memory caches. If you don't want to use an in-memory cache, we provide integrations for server-side SDKs to store data in persistent data stores like Redis or DynamoDB instead.

Client-side and mobile SDKs may have platform-specific storage mechanisms and can alternatively use the our relay proxy. To learn more, read Using a persistent feature store.

Multi-environment support

We designed our SDKs to work with one LaunchDarkly environment at at time. However, mobile application developers might want their applications to be able to access flags on multiple LaunchDarkly environments. We designed the mobile SDK to support behavior across multiple environments.

For example, if your LaunchDarkly account is set up to have different "Android", "iOS", and "Core" environments and/or projects, you can use the the multi-environment SDK feature to access flags in multiple places.

Mobile connection state

This feature also pertains specifically to mobile SDKs. Mobile applications are more likely than web / desktop software to lose their network connection. Our mobile SDKs provide additional functionality to monitor the connection state to LaunchDarkly.

Security

The client- and server-side SDKs have different security considerations.

Client-side SDKs

These SDKs typically run on customers' own devices. They can be compromised by users who unpack a mobile app to examine the SDK bytecode or use their browser's developer tools to inspect internal site data. As a result, you should never use a server-side SDK key in a client-side or mobile application.

Flag rules can include user identifiers or other PII that you may not want to transmit to client-side applications. Instead, client-side SDKs depend on LaunchDarkly's servers to safely store flag rules, and exercise them through LaunchDarkly's REST APIs.

Server-side SDKs

These SDKs operate within server-architected applications running on your own infrastructure or trusted cloud-based infrastructure. Neither of these locations is directly accessible by end users.
Because of the limited access to server-based applications, our server-side SDKs can safely receive flag data and rulesets without needing to obscure or filter out sensitive data.

Flag evaluations

The two types of SDKs evaluate feature flags differently. Different evaluation behavior supports data security and efficient data utilization.

Client-side SDKs

Client-side SDKs delegate flag evaluation to LaunchDarkly. When these SDKs are tasked with determining a user's flag variation, they send a REST API request to LaunchDarkly to determine the flag's value.

For security reasons, client-side SDKs cannot download and store an entire ruleset. Client-side SDKs typically run on customers' own devices, so they are vulnerable to having users investigate SDK content by unpacking the SDK on a mobile device or inspecting its behavior in a browser. Instead of storing potentially sensitive data, the client-side SDKs confirm and update flag rules by communicating with LaunchDarkly servers with REST API requests.

This approach is also beneficial from a data management perspective. Client-side SDKs' bandwidth requirements are lower than server-side SDKs' requirements because LaunchDarkly sends client-side SDKs less data.

Server-side SDKs

When requested, server-side SDKs evaluate feature flags to determine a user's flag variation. To do this, they execute an in-process flag evaluation algorithm and return the resulting value.

Server-side SDKs can evaluate flags because these SDKs know your complete flag ruleset. These SDKs can determine users' flag variations without having to make requests to LaunchDarkly's servers for every evaluated flag.

Server-side SDKs get the complete ruleset associated with an SDK key when initializing a connection to LaunchDarkly's servers. Through this persistent connection, LaunchDarkly will continuously update the SDK's cached flag ruleset whenever flag rules change on LaunchDarkly.

Keys

Before embedding an SDK key into your application's LaunchDarkly configuration, you must identify which category of SDK you're using so that you can select the appropriate SDK key.

The Account Settings page lists three keys for each environment:

  • SDK key
  • mobile key
  • client-side ID

Each of these keys grants different access levels to LaunchDarkly's APIs.

LaunchDarkly enforces that each of the SDK types use the appropriate key as described below. Requests made with one of the other two keys will be rejected. See "Language support' to identify which keys are used by each specific SDK.

Client-side SDKs

Configure JavaScript-based client-side SDKs to use the client-side ID. This ID grants these SDKs access to evaluate any flags, as long as the flag is associated with the provided key's environment and has the "Make this flag available to client-side SDKs" option enabled. Because you must manually connect every flag to a client-side SDK, you can restrict which flags are accessible by the client-side ID.

The client-side ID is public and does not need to be kept a secret.

Making flags available to client-side SDKs

Find the "Make this flag available to client-side SDKs" option on a flag's Settings tab.

Mobile SDKs

Configure mobile SDKs (plus other client-side SDKs not written in JavaScript) to use the mobile key. This key grants these SDKs evaluation rights to all flags associated with the provided key's environment. Unlike client-side IDs, mobile keys have access to evaluate all flags for the associated environment.

The mobile key is sensitive by nature and should be kept a secret. If a mobile key is exposed, you can reset it on the Account Settings page.

Server-side SDKs

Configure server-side SDKs to use the SDK key. This key grants server-side SDKs read-only access to all flag data associated with the provided key's environment. With this key, server-side SDKs can download the entire flag ruleset for all flags in the environment.

The SDK key is sensitive by nature and should be kept a secret. If an SDK key is exposed, you can reset it on the Account Settings page.

Language support

We offer SDKs for many languages and technologies. Some, but not all, languages have client- and server-side SDKs available.

Explore the following SDK reference guides for specific details about how to use LaunchDarkly with your tech stack:

SDK
Type
Key

Server-side

SDK key

Client-side (Mobile)

Mobile key

Client-side

Mobile key

Server-side

SDK key

Client-side

Client-side ID

Server-side

SDK key

Client-side (Mobile)

Mobile key

Client-side (Mobile)

Mobile key

Server-side

SDK key

Client-side

Client-side ID

Client-side

Client-side ID

Server-side

SDK key

Server-side

SDK key

Server-side

SDK key

Client-side

Client-side ID

Client-side (Mobile)

Mobile key

Client-side

Mobile key

Server-side

SDK key

Client-side (Mobile)

Mobile key


Client-side and server-side SDKs


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.