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.
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.
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
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.
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.
- The Activation API may already be installed and available if you already use the standard client-side Kameleoon platform.
When you update your experiment or feature flag configuration, the SDK can obtain the updated configuration in two different ways: polling or streaming.
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
- When intervals are moderately spaced, updating the configuration consumes very little memory and network resources.
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).
- 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 that you must subscribe to. To activate real-time streaming on your Kameleoon account, contact your Customer Success Manager or email firstname.lastname@example.org.
- 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.