Getting started with SDKs
Read time: 2 minutes
Last edited: Jun 18, 2021
This topic explains the prerequisites you must consider when you're setting up a LaunchDarkly SDK for the first time.
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:
- Determine what kind of SDK you need to use. Depending on your use case, you may need a server-side, client-side, or mobile 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. To learn more about SDKs, read Client-side and server-side SDKs.
- Identify the language you want to use. In some cases, we support multiple SDKs for a language. To learn more, read Available SDKs.
- Confirm that your tech stack's versions are compatible with the SDK you want to use. More information about SDK versioning is available in the documentation for a specific SDK, or in the SDK's readme in GitHub.
- (Optional) Determine if you need to use the Relay proxy. To learn more, read The Relay proxy.
All of our SDKs are thread-safe.
Here are some basic guidelines for implementing LaunchDarkly SDKs:
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 and server-side SDKs.
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 users, 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.
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.
Your SDK should only initialize once statically, and that instance should be the exclusive instance you use. When you create multiple SDK instances, previous instances may leak into memory and stay active long after the context they were created in is destroyed.
When you have enough of these instances running, they can cause bottlenecks in the connection to the streaming endpoint.