SDK overview

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:

Security Considerations

Client and server-side SDKs have different security considerations.

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.

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.

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.