Skip to main content

SDK overview

To connect your application to Unleash you need a client SDK for your programming language and an API token. The SDK handles connecting to the Unleash server instance and retrieving feature flags based on your configuration. All versions of Unleash (OSS, Pro, and Enterprise) use the same client SDKs.

Unleash provides official client SDKs for a number of programming languages. Additionally, our community has developed and contributed SDKs for other languages. So if you can't find your favorite language in the list of official SDKs, check out the list of clients written by our fantastic community.

Official SDKs

Server-side SDKs:

Server-side clients run on your server and communicate directly with your Unleash instance to evaluate your feature flags in their respective language. We provide these official clients:

Client-side SDKs

Client-side SDKs can connect to Unleash Edge or to the Unleash front-end API, but not to the regular Unleash client API.

Server-side SDK compatibility table

The below table shows what features the various server-side SDKs support. Note that certain features make sense only for some clients due to how the programming language works or due to how the client works.

Legend:

  • ✅: Implemented
  • ⭕: Not yet implemented, but we're looking into it
  • ❌: Not implemented, not planned
  • N/A: Not applicable to this SDK
note

If you see an item marked with a ❌ that you would find useful, feel free to reach out to us (on Slack, for instance) with your use case. It may not be something we can prioritize right now, but if you'd like to contribute it back to the community, we'd love to help you build it.

CapabilityJavaNode.jsGoPythonRuby.NETPHPRust
Category: Initialization
Async initialization
Can block until synchronized
Default refresh interval10s15s15s15s15s30s30s15s
Default metrics interval60s60s60s60s60s60s30s15s
Context providerN/AN/AN/AN/AN/A
Global fallback function
Flag Query: namePrefix
Flag Query: tags
Flag Query: project_nameN/A
Category: Custom Headers
static
function✅ (4.3)
Category: Built-in strategies
Standard
Gradual rollout
Gradual rollout: custom stickiness
UserID
IP
IP: CIDR syntax
Hostname
Category: Custom strategies
Basic support
Category: Strategy constraints
Basic support (IN, NOT_IN operators)
Advanced support (Semver, date, numeric, and extended string operators) (introduced in)✅ (5.1)✅ (3.12)✅ (3.3)✅ (5.1)✅ (4.2)✅ (2.1)✅ (1.3.1)
Category: Unleash Context
Static fields (environment, appName)
Defined fields
Custom properties
Category: isEnabled
Can take context
Override fallback value
Fallback function
Category: Variants
Basic support
Custom fallback variant
Custom weight
Custom stickiness
Strategy Variants
Category: Local backup
File-based backup
Category: Usage metrics
Can disable metrics
Client registration
Basic usage metrics (yes/no)
Impression data
Category: Bootstrap (beta)
Bootstrap from file
Custom Bootstrap implementation

Community SDKs ❤️

Here's some of the fantastic work our community has done to make Unleash work in even more contexts. If you still can't find your favorite language, let us know and we'd love to help you create the client for it!

Implement your own SDK

If you can't find an SDK that fits your requirements, you can also develop your own SDK. To make implementation easier, check out these resources:

  • Unleash Client Specifications - Used by all official SDKs to make sure they behave correctly across different language implementations. This lets us verify that a gradual rollout to 10% of the users would affect the same users regardless of which SDK you're using.
  • Client SDK overview - A brief, overall guide of the Unleash Architecture and important aspects of the SDK role in it all.

Client-side SDK behavior

The following section details the behavior of frontend / client-side SDKs when initializing and fetching flags with respect to network connectivity.

When the SDK is initialized in the application, an in-memory repository is set up and synchronized against the frontend API using the configured token and context. Note that the frontend API is hosted by either the Unleash Proxy/Edge or the upstream Unleash instance directly.

  1. All feature flag evaluation is performed by the Proxy/Edge or Unleash instance. A payload of all enabled flags and their variants (if applicable) is returned as a single request. Disabled flags are not included.

  2. When a page inside the application requests a feature flag, the SDK will return the flag state from memory. No network connection to the frontend API is performed.

  3. The SDK periodically syncs with the frontend API to retrieve the latest set of enabled flags

Working offline

Once they have been initialized, all Unleash clients will continue to work perfectly well without an internet connection or in the event that the Unleash Server has an outage.

Because the SDKs and the Unleash Proxy/Edge cache their feature flag states locally and only communicate with the Unleash server (in the case of the server-side SDKs and the Proxy) or the Proxy/Edge (in the case of front-end SDKs) at predetermined intervals, a broken connection only means that they won't get any new updates.

Unless the SDK supports bootstrapping, it will need to connect to Unleash at startup to get its initial feature flag data set. If the SDK doesn't have a feature flag data set available, all flags will fall back to evaluating as disabled or as the specified default value (in SDKs that support that).

Bootstrapping

By default, all SDKs reach out to the Unleash Server at startup to fetch their flag configuration. Additionally, some of the server-side SDKs and the Proxy (see the above compatibility table) also support bootstrapping, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can work without any network connection whatsoever.

Bootstrapping is also supported by the following front-end client SDKs: