Client-side and server-side SDKs
Read time: 5 minutes
Last edited: Dec 03, 2020
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.
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:
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, Flutter, 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:
|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.
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.
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.
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.
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.
The client- and server-side SDKs have different security considerations.
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.
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.
The two types of SDKs evaluate feature flags differently. The different evaluation behavior supports data security and efficient data utilization.
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.
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.
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.
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 considered confidential and should be kept a secret. If an SDK key is exposed, you can reset it on the Account Settings page.
The mobile key is not considered confidential and does not need to be kept a secret.
The client-side ID is not considered confidential and does not need to be kept a secret.
Find the "Make this flag available to client-side SDKs" option on a flag's Settings tab.
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 name||SDK type||Identifier|
|Android||Client-side (mobile)||Mobile key|
|C/C++ (client-side)||Client-side||Mobile key|
|C/C++ (server-side)||Server-side||SDK Key|
|Flutter||Client-side (mobile)||Mobile key|
|iOS||Client-side (mobile)||Mobile key|
|Node.js (client-side)||Client-side||Client-side ID|
|Node.js (server-side)||Server-side||SDK Key|
|React Native||Client-side (mobile)||Mobile key|
|Xamarin||Client-side (mobile)||Mobile key|