• HOME
  • INTEGRATIONS
  • SDKS
  • GUIDES
  • API DOCS
No results for ""
EXPAND ALL
CLOSE
launchdarkly.com

EDIT ON GITHUB

Client-side and server-side SDKs

Read time: 5 minutes
Last edited: Jul 23, 2020

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 cases.

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 TypeDetails
Client-sideThese 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-sideThese 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 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 SDKs 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 may include user identifiers or other personally identifiable information (PII) that you might not want to transmit to client-side applications. Consequently, client-side SDKs depend on LaunchDarkly's servers to safely store flag rules. To learn more, read Evaluation reasons.

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. The different evaluation behavior supports data security and efficient data utilization.

Client-side SDKs

Client-side SDKs are configured to operate for a singular user (identified or anonymous) at a time. When requested, these SDKs delegate to LaunchDarkly for the task of evaluating flags for this user. LaunchDarkly's services are responsible for evaluating flag rules for the specific user. Then, through either the SDK's streaming or polling connections, LaunchDarkly notifies the SDK of the evaluation results. The SDK then stores these results for quick lookup by the host applications.

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 through streaming connections or 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.

You can think of each flag evaluation as a pure function, where we use the provided user context along with the complete ruleset to see if your user should be included in an evaluation or not. It is important to note that we pass along rule data not user data. If a user does not have the correct attributes locally, then it will not get evaluated by the rules that are cached by the SDK.

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. To identify which keys are used by each specific SDK, read Language support.

SDK key

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.

Mobile key

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.

Client-side ID

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.

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 nameSDK typeIdentifier
.NETServer-sideSDK Key
AndroidClient-side (mobile)Mobile key
C/C++ (client-side)Client-sideMobile key
C/C++ (server-side)Server-sideSDK Key
ElectronClient-sideClient-side ID
ErlangServer-sideSDK Key
GoServer-sideSDK Key
HaskellServer-sideSDK Key
iOSClient-side (mobile)Mobile key
JavaServer-sideSDK Key
JavaScriptClient-sideClient-side ID
LuaServer-sideSDK Key
Node.js (client-side)Client-sideClient-side ID
Node.js (server-side)Server-sideSDK Key
PHPServer-sideSDK Key
PythonServer-sideSDK Key
ReactClient-sideClient-side ID
React NativeClient-side (mobile)Mobile key
RokuClient-sideMobile key
RubyServer-sideSDK Key
XamarinClient-side (mobile)Mobile key