SDK Overview
DevCycle has both client-side and server-side SDKs. This page serves to describe the differences between these SDK types and how to handle them. Implementation and usage change depending on which type of SDK is being used.
Explore our SDK Features and Functionality to discover how to impliment your solutions using the DevCycle SDKs.
- Clide Side SDKs
- Server-Side SDKs
DevCycle client-side SDKs are meant for single-user contexts. This means that the SDKs have a persistent data store for the user while the SDK is being used. Evaluation of Features happens directly on the client's device. These SDKs also include the Mobile SDKs. For more information on the difference between mobile and standard client-side SDK keys, read API and SDK keys.
The current Client-Side SDKs are:
JavaScript SDK
React SDK
iOS SDK
Android SDK
React Native SDK
Flutter SDK
Server-side SDKs are used in multi-user contexts where each call to the SDK will likely be for a different user. Each call to a server SDK function requires the user's ID and any other targeting information to be passed in on every function call. These SDKs are made for infrastructure, backend, and other such services.
The current Server-Side SDKs are:
NodeJS SDK
Local and Cloud Bucketing
Go SDK
Local and Cloud Bucketing
PHP SDK
Cloud Bucketing
Python SDK
Local and Cloud Bucketing
Ruby SDK
Local and Cloud Bucketing
Java SDK
Cloud Bucketing
Java SDK
Local Bucketing
.NET SDK
Cloud Bucketing
.NET SDK
Local Bucketing
Difference between Local and Cloud Bucketing
- Local Bucketing SDKs
- Cloud Bucketing SDKs
Local bucketing does all of the calculations locally using extremely performant Web Assembly code. The project's environment configuration is downloaded upon initialization of the SDK, and all future SDK calls will calculate values locally within the SDK. This approach will guarantee responses from the SDK in 1-10ms. The configuration will be updated at a configurable polling interval.
The logic which determines what a user gets is calculated in the cloud, using workers at the edge which are available globally. Every function within the SDK will reach out to these edge workers and respond with the response with extremely low latency. The Cloud Bucketing SDKs will cause a large number of outbound requests as each SDK call will reach out to the DevCycle edge servers. However, the cloud bucketing SDKs are useful in cases in which a much older version of the given language is being used, as Local Bucketing generally only supports newer versions of languages.
SDK Proxy
Designed for cases where the language design doesn't support a long lived background process to contain the Local Bucketing engine and configuration data; the Local Bucketing Proxy was made to emulate the Cloud Bucketing API's and allow and SDK to have greater performance; close to that of the local bucketing SDKs. For more information see SDK Proxy.