Note: There are two similarly named, but distinct approaches to managing features. Feature Flags are detailed below. Feature Management is a separate approach - a lightweight spreadsheet-based "Remote Config" allowing you to enable/disable features based on specific conditions, but not as part of an experiment.
What are Feature Flags in Webtrends Optimize?
We view feature flags less as a separate type of experience, and more of an application.
The component parts of a feature flag are typically exactly the same as an experiment:
Content: As Javascript, CSS, Text, Numbers, True/false, etc.
Throttling: % exposure for a given variant
Stickiness: Making sure users continue to see the same variations/features
Segmentation: Deciding who should get the experience
State: Staging mode, set live, turned off
Location: Dev environment, production, particular pages, etc.
Behavioural measurement: Understanding performance of what you're doing.
Rollouts and optimals/100% experiences: Progressive ramp-up and eventual delivery to all users.
So, whether you're running a client-side AB test or Feature Flags to toggle components in your single-page app, the functionality you need is exactly the same.
Where other platforms have an entirely separate feature flag/full-stack offering for you to purchase and learn, we keep everything consistent and in one place.
The Optimize platform was built to be API-first, and so any full-stack offerings we have involve using the same APIs as the Javascript tag, to talk to the same servers, and fetch the same experiments. The only difference is the "location" and other parameters you pass into the API call.
Where could you use Feature Flags?
Feature Flags themselves are a fairly broad term. Here are some applications for where we've most commonly seen the technique used:
In a Single-Page App, via. APIs
The service where decisions and data are held is communicated-with over API. You can contact OTS (Optimize Testing Service) through REST APIs, and fetch your decisions / measure behaviour, or a hybrid approach
A common approach, if using this scenario, is wrapping a React App in a Context, which makes the call our to OTS, fetches decisions, and stores the information in-state, such that you can then consume that data anywhere inside of your application. You then have the ability, given the whole app is wrapped, to mask the page and make sure no content-flickering happens. Higher-level components having the required data also means that as the component-tree renders, decisions are already understood. This should avoid re-hydration issues.
<WTOContext
whileLoading={ <LoadingSpinner /> }
afterLoaded={ <MyApp /> }
/>
In a Single-Page App, via. SDK
If you would rather be made aware of decisions than have to fetch them yourself, we can fetch the required flags in our Javascript SDK/tag/snippet.
In this scenario, the loading process of the website is roughly:
Web page delivered to user, containing the Webtrends Optimize tag (wt.js)
Tag fires - downloads and executes
The tag has it's natural behaviour of fetching and running client-side experiments.
The tag also fetches feature-flags
Flags are stored in a useful variable
Flags are also "broadcast" in an event for your Single-Page App to hook into.
In this scenario, you will:
Find all decisions fetched for that user under
WT.FeatureFlags.assignments.Be proactively informed of decisions fetched. By default, this will be in an event that we publish on the window, but there is flexibility to trigger a method available in your application's code as well.
If the application wishes to fetch data, we expect code similar to:
var assignments = window.WT?.FeatureFlags?.assignments || null;
if(assignments){ // depending on when you run the code, we may already have assignments
this.state.flags = assignments
} else { // wait to be fetched
const [flags, setFlags] = useState({});
window.addEventListener("wto:featureflags:ready", e => {
setFlags(e.detail || {});
});
}
In a server environment, via. API
Some functionality can only be toggled on a server itself. For example, changing a pricing model, routing requests between different servers, or for some websites e.g. those that run on PHP, building the page template itself.
In cases like this, you should use the aforementioned OTS REST API to fetch your feature-flags, and make decisions about where to store this information yourself.
In edge workers
Some modern websites have a heavy reliance on Edge Workers, both for routing requests and also performing actions such as building pages.
In this scenario, we can either store decisions in cookies which you can then pull out from your headers, or you can make the API calls within the Edge worker itself.
The process for both of these should hpoefully be clear from the detail above.