Technical considerations
Kameleoon SDKs are designed with an important architectural design decision in mind. All of the SDKs comply with a zero latency policy. This means that we don't allow any blocking remote server calls used to bucket users in an experiment. Even the fastest remote call would add 20 ms of latency to your application. If servers are even slower to reply than usual, this delay can increase to hundreds of milliseconds or more, or even completely block the loading of your web application for the end user.
We believe that web performance is of paramount importance, and adding A/B testing or feature flagging capabilities should not come at the cost of increased web page rendering time. For this reason, we ensure that the use of our SDKs has no impact on the performance of the host platform.
However, having a zero latency policy does impose some constraints, which we detail in the following sections.
Server-side SDKs
Kameleoon keeps custom data about your visitor stored locally on your server or infrastructure, not fetched from a remote Kameleoon server. We implement this by storing a map of visitor data directly on RAM (where the keys are the visitorCodes). For example, if you use the addData() method, the data is stored in the RAM of the server hosting the SDK (usually an application server).
To change the maximum amount of RAM a Kameleoon SDK can use for this map, use the visitor_data_maximum_size configuration parameter available in each SDK. The default value is 500MB, which mean the RAM overhead of the SDK will not exceed 500MB on your host server. However, if you don't use a lot of custom data, the overhead will be much lower.
Since the visitor data is kept in RAM, it will be lost if you restart your application server. This is usually not an issue, as important custom data is typically fetched from a persistent database and then assigned to the current visitor. In this case, a reboot would only affect the custom data of sessions that were active when the reboot occurred.
Client-side SDKs
Since a client-side SDK runs on users' devices, your app must fetch the configuration of all active experiments and feature flags at the start of the session. This introduces a mandatory remote server call with an associated callback, which means your application code that uses the JavaScript / TypeScript SDK can't run experiments or apply feature flags before this callback finishes executing. Aside from this one initial remote call, there is no other performance impact from using a client-side SDK. The SDK code allocates your variations for experiments locally without any remote API calls. The SDKs make tracking calls asynchronously in a non-blocking way (in the background).
Kameleoon keeps custom data about your visitor stored locally on your server or infrastructure, not fetched from a remote Kameleoon server. For example, if you set custom data for a given visitor, we store it in your server or infrastructure, not on our (remote) side.
Kameleoon implements this by storing a map of visitor data directly in the browser's LocalStorage. Unless you use an unusually large amount of custom data, you shouldn't run into issues with storage limits on the browser.
To change the maximum amount of storage the SDK can use for this map, use the visitor_data_maximum_size configuration parameter available in each SDK. The default value is 1MB.
When to use the Activation API instead of a client-side SDK
For optimal performance on web applications, you can use our Activation API in tandem with a standard web experimentation implementation. In this scenario, you embed the configuration data directly in the Kameleoon application file (the JavaScript file contains both the engine code and the configuration of active experiments). This approach changes the way you work with Kameleoon, including using a different API and not having an npm package to install (you install the client-side code by integrating a standard JavaScript tag on the HTML source page). You can read more about this approach in the Activation API documentation.
Advantages of using an SDK:
- Easier installation (using an npm package).
- The API is similar to our other (server-side) SDKs. For example, if you use the NodeJS SDK on the back-end, you can use the same familiar API calls on the front-end.
- Easier integration with modern JavaScript frameworks, such as React, Angular, or Vue.js
Advantages of using the Activation API:
- Better performance (no initial remote server call required for each session).
- Ability to use front-end Kameleoon tracking, as well as integrations with a third-party analytics platform.
- Our standard JavaScript engine contains more targeting options for you to use in your experiments.
- The Activation API may already be installed and available if you already use the standard client-side Kameleoon platform.
In summary, unless you're using a modern framework, we recommend using the Activation API, because of the additional integration and targeting features, as well as the improved performance over the client-side JavaScript SDK.
Configuration Updates
When you update your experiment or feature flag configuration, the SDK can obtain the updated configuration in two different ways: polling or streaming.
Polling
This is the default way that all SDKs update the configuration. The SDK sends a request to our CDN (Cloudflare) at regular intervals to retrieve the configuration. By default, the SDKs refresh the configuration every 60 minutes. You can set a custom interval in the SDK configuration (using the actions_configuration_refresh_interval parameter).
Main benefits:
- When intervals are moderately spaced, updating the configuration consumes very little memory and network resources.
Streaming
This mode allows the SDK to automatically apply the new configuration without delay. When streaming is enabled, the Kameleoon SDK is notified of any changes to the configuration in real time, thanks to server-sent events (SSE).
Main benefits:
- Streaming makes it possible to update your configuration immediately (no waiting for the next polling cycle).
- Uses less network traffic than polling at short intervals. Streaming does not send periodic requests. It opens the connection once and keeps it permanently open and remain ready to receive data.
This is a premium option. If you wish to activate real-time streaming on your Kameleoon account, please contact your Customer Success Manager or send us an email at support@kameleoon.com.
This option is not yet available in all SDKs. See the SDK compatibility matrix to see if your preferred language supports streaming.