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.

Streaming architecture overview

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

• Scalable. Split is currently serving more than 50 billion split feature 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 and flexible architecture uses a dual-layer CDN to serve split flags anywhere in the world in less than 200 ms. Split updates can be streamed to Split's SDKs sub second or can be retrieved on configurable polling intervals; you choose. Our SDKs store the split definitions locally to serve splits 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 treatment.
• 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 split evaluations without exposing this data to third parties.

Streaming versus polling

Split updates can be streamed to Split's SDKs sub second or can be retrieved on configurable polling intervals.

When streaming, Split utilizes server-sent events (SSE) to notify Split’s SDKs when a split definition is updated, a segment definition is updated, or a split is killed. For split and segment definition updates, the split SDK reacts to this notification and fetches the latest split definition or segment definition. When a split is killed, the notification will trigger a kill event immediately. When the SDK is running with streaming enabled, your updates will take effect in milliseconds.

Enable streaming when it is important to,

• Reduce network traffic caused by frequent polling.
• Propagate split updates to every customer and/or service in real-time.

When polling, the SDK asks the server for updates on configurable polling intervals. Each request is optimized to fetch delta changes resulting in small payload sizes.

Utilize polling when it is important to,

• Maintain a lower memory footprint. Each streaming connection is treated as an independent request.
• Support environments with unreliable connectivity such as mobile networks. Mobile environments benefit from a low-frequency polling architecture.
• Maintain robust security practices. Maintaining an always-open streaming connection poses risk.
• Maintain control over frequency and when to initiate a network call.

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 splits. 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 split about such degradation.