When you integrate Split SDKs, consider the following to make sure that you have the correct set up 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 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 serveral SDKs across various 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 feature flag definitions 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, refer to the Split Synchronizer and Proxy guide.
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, or received a text message from service provider, you've likely experienced Split.
- Reliable and fast. Our scalable and flexible architecture uses a dual-layer CDN to serve feature flags anywhere in the world in less than 200 ms. In most instances, Split rollout plan updates are streamed to Split's SDKs, which takes a fraction of a second. In less than 10% of cases, for very large feature flag definitions (or large dynamic configs) or segment updates with a large number of key changes, a notification of the change is streamed and the changes are retrieved by an API fetch request. Our SDKs store the Split rollout plan locally to serve feature flags without a network call and without interruption in the event of a network outage.
- Independent with no Split dependency. Split ships the evaluation engine to each SDK creating a weak dependency with Split's backend and increasing both speed and reliability. There are no network calls to Split to decide a user's treatment.
- Secure with no PII required. 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.
Streaming versus polling
Split updates can be streamed to Split's SDKs sub second or retrieved on configurable polling intervals.
When streaming, Split utilizes server-sent events (SSE) to notify Split’s SDKs when a feature flag definition is updated, a segment definition is updated, or a feature flag is killed. For feature flag and segment definition updates, the Split SDK reacts to this notification and fetches the latest feature flag definition or segment definition. When a feature flag is killed, the notification triggers a kill event immediately. When the SDK is running with streaming enabled, your updates 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
Streaming is currently supported for the below SDKs with the minimum version shown below.
- .NET 6.1.0
- Android 2.6.0
- Browser 0.1.0
- Go 5.2.0
- iOS 2.7.0
- Java 4.0.0
- JavaScript 10.12.0
- Node.js 10.12.0
- React 1.2.0
- React Native 0.0.1
- Redux 1.2.0
- Ruby 7.1.0
- Python: 8.3.0
SDK types
Our supported SDKs fall into two categories:
Type | Overview |
---|---|
Client-side |
|
Server-side |
|
Security considerations
Client- and server-side SDKs have different security considerations:
Type | Security Considerations |
---|---|
Client-side |
|
Server-side |
|
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.
Within Split, the following three types of keys each provide different levels of access to Split's API:
Type | Overview |
---|---|
Server-side |
|
Client-side |
|
Admin |
|
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. Go to our GitHub repository for more information.
SDK | API Key/Type | Links |
---|---|---|
Android | client-side | Docs & GitHub |
Angular utilities | client-side | Docs & GitHub |
Browser | client-side | Docs & GitHub |
Flutter plugin | client-side | Docs & GitHub |
iOS | client-side | Docs & GitHub |
JavaScript | client-side | Docs & GitHub |
React | client-side | Docs & GitHub |
React Native | client-side | Docs & GitHub |
Redux | client-side | Docs & GitHub |
GO | server-side | Docs & GitHub |
Java | server-side | Docs & GitHub |
.NET | server-side | Docs & GitHub |
Node.js | server-side | Docs & GitHub |
PHP | server-side | Docs & GitHub |
PHP Thin-Client | server-side | Docs & GitHub |
Python | server-side | Docs & GitHub |
Ruby | server-side | 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 service
By default, Split's SDKs keep segment and feature flag definitions synchronized in an in-memory cache for speed at evaluating feature 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 Split Synchronizer to maintain an external cache like Redis. To learn more, read about Split Synchronizer.
Proxy service
Split Proxy enables you to deploy a service in your own infrastructure that behaves like Split's servers and is used by both server-side and client-side SDKs to synchronize the flags without directly connecting to Split's backend.
This tool reduces connection latencies between the SDKs and the Split server, and can be used when a single connection is required from a private network to the outside for security reasons. To learn more, read about Split Proxy.
Supported agents
Split's real user monitoring (RUM) agents collect 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 feature flag changes and alert the owner of the feature flag about such degradation.
Agent | API Key/Type | Docs |
---|---|---|
Android | client-side | Docs |
iOS | client-side | Docs |
Browser | client-side | Docs |
Comments
0 comments
Please sign in to leave a comment.