Communication Strategy Between SDKs and Harness Feature Flags

Updated 3 days ago by Archana Singh

This topic describes how the SDKs communicate with Harness Feature Flags to receive flag changes.

In this topic:

Before You Begin

Visual Summary

Above diagram explains the flow a feature flag follows to evaluate the target.

It can be explained by using several use cases:

Use Case 1: Feature Flag with no Rules and no Prerequisites

Flag Type: Boolean

Flag state: ON

  1. If the flag is ON, check for any prerequisites, and additional rules.  If there are none, the default ON variation is returned, which in the above example is ‘True’.
  2. Is the flag OFF, no rules are ever evaluated, and it returns the default OFF variation.  In the above example this is ‘False’

Use Case 2: Feature Flag with Variation Target Mapping

Flag Type: Boolean

Flag state: ON

The flag is ON, with target mapping.  This rule says serve False to target ‘xxxx’. 

This implies that if the user evaluating the flag is ‘xxxx’ they'll receive a False variation.  Everyone else will receive ‘True’ variation.

How do SDKs Communicate with Feature Flags?

SDK maintains all the feature flag details locally in its cache and evaluates flags based on it. The SDKs use streaming and a polling strategy to keep the local cache in sync with the flag configurations.

Streaming

Streaming provides a persistent connection to the SDKs. Harness Feature-Flags uses Server-Sent Events to send messages to the servers whenever the feature flag rules change. This has the following benefits:

  • Updates flag in a few hundred milliseconds.
  • Avoids any delays by delivering real-time updates to end-users/targets. 
  • Ensures that every change that is made is dispersed to every user in real-time propagating them across every server.

Polling

In polling mode, you can define the interval of time at which you want to receive updates of flag states from the Feature Flag. The SDK will then make HTTP requests to Feature Flags to retrieve flag state changes.

It is important to know that the Harness Feature Flag does not send any information as part of these requests, it is simply a query to update the status of a flag on the SDK side.

Communication Loop Between Harness and the SDKs

Server-side

Client-side

The client authenticates with a server using an API Key.

The client authenticates with a server using an API key. The client is initialized for a specific target.

Configuration is fetched and cached in the memory.

All the Flag evaluations are fetched from the server and cached locally.

·  One call to fetch all Feature Flag configurations for the environment.

·  One call to fetch all Target Group configurations for the environment.

 

Stream is opened to the server.

 

In the case of streaming mode, a connection is open to the stream endpoint.

·  On any change in flag, an event is pushed to the SDK.

·  SDK fetches the flag value and caches it locally.

In case of polling mode:

Config is polled periodically (default 60 seconds), and the cache is updated.

 

 

All the evaluations are run against the cached data.

 


Please Provide Feedback