You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document explains how configuration is managed throughout its lifecycle in the Eppo SDK.
4
+
5
+
## Components Overview
6
+
7
+
The SDK's configuration management is built around several key components that work together:
8
+
9
+
-**ConfigurationFeed**: A broadcast channel that serves as the central communication point between components
10
+
-**ConfigurationStore**: Maintains the currently active configuration used for all evaluations
11
+
-**ConfigurationPoller**: Periodically fetches new configurations from the Eppo API
12
+
-**PersistentConfigurationCache**: Persists configuration between application restarts
13
+
14
+
## Communication Flow
15
+
16
+
The ConfigurationFeed acts as a central hub through which different components communicate:
17
+
18
+
19
+
20
+
When a new configuration is received (either from network or cache), it's broadcast through the ConfigurationFeed. Components subscribe to this feed to react to configuration changes. Importantly, configurations broadcast on the ConfigurationFeed are not necessarily activated - they may never be activated at all, as they represent only the latest discovered configurations. For components interested in the currently active configuration, the ConfigurationStore provides its own broadcast channel that only emits when configurations become active.
21
+
22
+
## Initialization Process
23
+
24
+
During initialization, the client:
25
+
26
+
1.**Configuration Loading Strategy**:
27
+
-`stale-while-revalidate`: Uses cached config if within `maxStaleSeconds`, while fetching fresh data
28
+
-`only-if-cached`: Uses cached config without network requests
29
+
-`no-cache`: Always fetches fresh configuration
30
+
-`none`: Uses only initial configuration without loading/fetching
31
+
32
+
2.**Loading cached configuration**:
33
+
- If `initialConfiguration` is provided, uses it immediately
34
+
- Otherwise, tries to load cached configuration
35
+
36
+
3.**Network Fetching**:
37
+
- If fetching is needed, attempts to fetch until success or timeout
38
+
- Applies backoff with jitter between retry attempts (with shorter period than normal polling)
39
+
- Broadcasts fetched configuration via ConfigurationFeed
40
+
41
+
4.**Completion**:
42
+
- Initialization completes when either:
43
+
- Fresh configuration is fetched (for network strategies)
44
+
- Cache is loaded (for cache-only strategies)
45
+
- Timeout is reached (using best available configuration)
46
+
47
+
## Ongoing Configuration Management
48
+
49
+
After initialization:
50
+
51
+
1.**Polling** (if enabled):
52
+
- ConfigurationPoller periodically fetches new configurations
53
+
- Uses exponential backoff with jitter for retries on failure
54
+
- Broadcasts new configurations through ConfigurationFeed
55
+
56
+
2.**Configuration Activation**:
57
+
- When ConfigurationStore receives new configurations, it activates them based on strategy:
58
+
-`always`: Activate immediately
59
+
-`stale`: Activate if current config exceeds `maxStaleSeconds`
60
+
-`empty`: Activate if current config is empty
61
+
-`next-load`: Store for next initialization
62
+
63
+
3.**Persistent Storage**:
64
+
- PersistentConfigurationCache listens to ConfigurationFeed
65
+
- Automatically stores new configurations to persistent storage
66
+
- Provides cached configurations on initialization
67
+
68
+
## Evaluation
69
+
70
+
For all feature flag evaluations, EppoClient always uses the currently active configuration from ConfigurationStore. This ensures consistent behavior even as configurations are updated in the background.
0 commit comments