Skip to main content

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).

tip

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.

caution

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.

tip

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​

The real-time streaming 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.

Availability:

  • This is a premium option that you must subscribe to. To activate real-time streaming on your Kameleoon account, contact your Customer Success Manager or email support@kameleoon.com.
  • The PHP SDK does not support streaming due to technical constraints. The PHP SDK currently can't listen for configuration updates in a non-blocking way because the PHP SDK does not persist between requests. Each request creates a new SDK instance that destroys itself as soon as it receives a response.
  • For other languagues, see the SDK compatibility matrix to see the minimum supported version in your preferred language.