SDK Overview – Split Help Center

Overview

When you integrate Split SDKs you will want to consider the following to make sure that they have the correct setup depending on your use case, customers, security considerations, and architecture.

Understand Split's architecture. Split's SDKs were built to be scalable, reliable, fast, independent, and secure.
Determine which SDK type. Depending on your use case and your application stack you may need a server-side or client-side SDK.
Understand security considerations. Client and server-side SDKs have different security considerations to be considered when managing and targeting using your customers' PII.
Determine which API key. In Split there are three types of keys with each providing different levels of access to Split's API. Understand what each key provides access to and when to use each API key.
Determine which SDK language. Split supports SDKs across a variety of languages. With Split, you can use multiple SDKs if your product is comprised of applications written in multiple languages.
Determine if you need to use the Split Synchronizer & Proxy. By default, Split's SDKs keep segment and split data synchronized as users navigate across disparate systems, treatments, and conditions. However, some languages, do not have a native capability to keep a shared local cache of this data to properly serve treatments. For these cases, we built the Split Synchronizer. To learn more, read about the Split Synchronizer and Proxy.

Architecture Overview

Split's SDKs were built to be scalable, reliable, fast, independent, and secure.

Scalable. Split is currently serving more than 50 billion flag evaluations per day. If you've shopped online, purchased an airline ticket, received a text message from service provider, you've likely experienced Split, you just didn't know it!
Reliable & Fast. Our scalable architecture uses a dual-layer CDN to serve flags anywhere in the world in less than 200 ms. Our SDKs store the feature flag definitions locally to serve flags without a network call allowing them to continue to operate in case of a network outage.
Independent with no Split dependency. Unlike other cloud based feature flagging providers, Split ships the evaluation engine to each SDK creating a weak dependency with Split's backend and increasing both speed and reliability. Put simply, there are no network calls to Split to decide a users flag state.
Secure with no PII required. Unlike other cloud based feature flagging providers, no customer data needs to be sent through the cloud to Split. Use customer data in your feature flag evaluations without exposing this data to third parties.

SDK Types

Our supported SDKs fall into two categories:

Type	Overview
Client-side	Designed to be used by a single traffic type in the browser, mobile device, or mobile application Intended to be used in a potentially less secure environment This includes Split's Javascript, iOS and Android SDKs
Server-side	These SDKs are designed to work for multiple traffic types, like users or customers (many of them per SDK) as opposed to client-side that are bound to one (typically a single user or account in session) Intended to be used in a secure environment, such as your infrastructure

Security Considerations

Client and server-side SDKs have different security considerations.

Type

Security Considerations

Client-side

These SDKs run on the browser or in a mobile device, they can be compromised by users unpacking a mobile app or use the browser's developer tools to inspect the page
Client-side SDK APIs are more restricted in regards to what information they can access it's a less secure environment
For example, client-side SDKs uses a specific endpoint (/mySegments) which only returns a list of segments in which the key used during instantiation is included
This provides for a much smaller amount of data, allowing for a smaller memory footprint in memory constrained environments of the browser and mobile apps

Server-side

These SDKs operate within your own infrastructure making them not accessible by end users
When targeting by private or sensitive data on the server-side, this information won't leave your infrastructure, keeping your sensitive data under your control

API Keys

Typically you need one API key per Split environment, and additionally you may want to issue extra API keys per microservice of your product using Split for better security isolation. You must identify which type of SDK you're using to ensure you select the appropriate API key type.

In Split there are three types of keys with each providing different levels of access to Split's API.

Type	Overview
SDK	Configure server-side SDKs to use the SDK api key Grants access to fetch splits and segments associated within the provided API key's environment Never expose SDK keys in untrusted contexts Do not put your SDK API keys in client-side SDKs If you accidentally expose your SDK API key, you can revoke it in the APIs tab in Admin Settings
Browser	Configure client-side SDKs to use the browser api key Grants access to fetch splits and segments for the provided key within the provided API key's environment
Admin	Use for access to Split's developer admin API This key provides broader access to multiple environments unlike the other API keys that are scoped to a specific environment Do not share this API key with your customers If you accidentally expose your admin API key, you can revoke it in the APIs tab in Organization Settings

Supported SDKs

Using Split involves using one of our SDKs. The Split team builds and maintains these SDKs for some of the most popular language libraries and are available under open source licenses. Head to our GitHub repository to for more information.

SDK	Type	API Key	Links
Android	client-side	browser	Docs & GitHub
iOS	client-side	browser	Docs & GitHub
Javascript	client-side	browser	Docs & GitHub
GO	server-side	SDK	Docs & GitHub
Java	server-side	SDK	Docs & GitHub
.NET	server-side	SDK	Docs & GitHub
Node.js	server-side	SDK	Docs & GitHub
PHP	server-side	SDK	Docs & GitHub
Python	server-side	SDK	Docs & GitHub
Ruby	server-side	SDK	Docs & GitHub

Evaluator Service

For languages with no native SDK support, Split offers the Split Evaluator, a small service capable of evaluating all available features for a given customer via a REST endpoint. This service is available as a Docker container for ease of installation and is compatible with popular framework like Kubernetes when it comes to supporting standard health checks to achieve reliable uptimes. Learn more about the Split evaluator.

Synchronizer & Proxy Service

By default, Split's SDKs keep segment and split data synchronized in an in-memory cache for speed at evaluating flags. However, some languages, do not have a native capability to keep a shared local cache of this data to properly serve treatments. For these cases, we built the Split Synchronizer to maintain an external cache like Redis. To learn more, read about the Split Synchronizer and Proxy.

Supported Agents

Split's real user monitoring (RUM) agent collects detailed information about your users' experience when they visit your application. This information is used to analyze site impact, measure the degradation of performance metrics in relation to split changes and alert the owner of the flag about such degradation.

Agent	Type	API Key	Docs
Javascript	client-side	browser	Docs