Flag update flow
This section describes how the changes in the CloudBees Feature Management dashboard affects flag values on the end device (mobile, web, backend) and how these changes can be controlled by the developer.
Stateless architecture CloudBees Feature Management uses a stateless architecture by default, which means that each SDK pulls a static JSON file from CloudBees Feature Management cloud storage. The CloudBees Feature Management stateless architecture has a few key advantages:
Note - CloudBees Feature Management uses Server Sent Event (SSE) to push to the SDKs a message to download a new JSON config file on config change, so changes are propagated to the clients instantly upon modification. |
SDK setup flow
The client SDK setup flow operates in the following sequence:
-
Synchronous local storage fetching:
-
The application calls the Rox SDK setup function
-
The SDK checks for existing configuration in local storage
-
The configuration is applied synchronously
-
Setup function returns with all configured Experiments applied on the device
-
-
Asynchronous network fetching
-
In Parallel to the local storage flow, an asynchronous network request is called from the SDK to the CloudBees Feature Management Storage services
-
When the network request is returned:
-
Configuration is applied
-
Configuration is saved on local storage
-
-
SDK foreground configuration fetching flow
On relevant clients (mobile, TV, etc.) when the SDK identifies a foreground event, it triggers an asynchronous configuration fetching sequence to get a new configuration (if one exists) on CloudBees Feature Management servers.
Flag freeze
See Understanding a flag freeze for information on when and how to freeze and unfreeze flags.
Server side SDK update flow
-
Server-side SDKs fetch a new configuration file periodically. The various settings for each SDK are listed below: default period is 30 seconds.
SDK |
Default (in seconds) |
Minimum (in seconds) |
JVM |
60 |
30 |
.NET |
60 |
30 |
Node.js |
60 |
30 |
JS SSR |
60 |
30 |
Python |
60 |
30 |
Go |
60 |
30 (see additional notes) |
PHP |
30 |
30 (see additional notes) |
C |
60 |
30 (see additional notes) |
C++ |
60 |
30 (see additional notes) |
-
To change the default time frame, use
FetchInterval
/fetchIntervalInSec
at theRoxOptions
object, example:
JVM | .NET | Node.js | Python | Go | PHP | C | C++ |
---|---|---|---|---|---|---|---|
|
|
|
|
func setupRollout() { options := server.NewRoxOptions(server.RoxOptionsBuilder{ Version: "2.0.0", FetchInterval: time.Minute }) rox = server.NewRox() } |
|
|
|
-
Additonal notes
-
Go - The option parameter tye is
time.duration
is in nano-seconds. -
C/C++ - There is an additional
0
option permitted to indicate that the fetch will not be periodic. -
PHP - PHP is different from other server side SDKs as it’s not a live server, but a cache on the storage with a strategy that expires every 30 seconds. We use
Kevinrob\GuzzleCache\CacheMiddleware
with a strategy. == Configuration fetched handler
-
See Configuration fetched handler for information on how to identify when the SDKs have loaded the configuration from the local storage or network.