Skip to main content

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.

tip

Explore our SDK Features and Functionality to discover how to implement your solutions using the DevCycle SDKs.

Clide 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:

Server-Side SDKs​

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:

Difference between Local and Cloud Bucketing​

Local Bucketing SDKs​

Local Bucketing does all calculations locally using extremely performant WebAssembly 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.

Cloud Bucketing SDKs​

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.