Storage Service
The SDK operates in a stateless mode by default, meaning each get_flag call triggers a fresh evaluation of the flag against the current user context.
To optimize performance and maintain consistency, you can implement a custom storage mechanism by passing a storage parameter during initialization. This allows you to persist feature flag decisions in your preferred database system (like Redis, MongoDB, or any other data store).
Key benefits of implementing storage:
- Improved performance by caching decisions
- Consistent user experience across sessions
- Reduced load on your application
The storage mechanism ensures that once a decision is made for a user, it remains consistent even if campaign settings are modified in the VWO Application. This is particularly useful for maintaining a stable user experience during A/B tests and feature rollouts.
How to Implement a Storage Service
Storage Service is optional while instantiating the VWO SDK. However, to ensure sticky variation assignments, we recommend implementing it.
Usage
class StorageConnector
def get(feature_key, user_id)
# Return stored data based on feature_key and user_id
end
def set(data)
# Store data using data[:feature_key] and data[:user_id]
end
end
vwo_client = VWO.init({
account_id: '123456',
sdk_key: '32-alpha-numeric-sdk-key',
storage: StorageConnector.new
})
Storage Service should expose two methods: get and set. These methods are used by VWO whenever there is a need to read or write from the storage service.
Method Name | Params | Description | Returns |
---|---|---|---|
get | feature_key, user_id | Retrieve stored data corresponding to feature_key and user_id | Returns a matching user-feature data mapping corresponding to feature_key and user_id passed |
set | data | Store user-feature data mapping | null |
Updated 28 days ago