Skip to content

Commit 84f71bd

Browse files
Merge pull request #298775 from zhiyuanliang-ms/zhiyuanliang/update-js-fm-doc
Azure App Configuration - Update JS Feature Management doc
2 parents 54d800b + d4f77ab commit 84f71bd

File tree

2 files changed

+119
-3
lines changed

2 files changed

+119
-3
lines changed

articles/azure-app-configuration/feature-management-javascript-reference.md

Lines changed: 118 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -449,6 +449,96 @@ When defining an audience, users and groups can be excluded from the audience. E
449449

450450
In the above example, the feature is enabled for users named `Jeff` and `Alicia`. It's also enabled for users in the group named `Ring0`. However, if the user is named `Mark`, the feature is disabled, regardless of if they are in the group `Ring0` or not. Exclusions take priority over the rest of the targeting filter.
451451

452+
### Targeting in a Web Application
453+
454+
An example web application that uses the targeting feature filter is available in this [example](https://github.com/microsoft/FeatureManagement-JavaScript/tree/preview/examples/express-app) project.
455+
456+
In web applications, especially those with multiple components or layers, passing targeting context (`userId` and `groups`) to every feature flag check can become cumbersome and repetitive. This scenario is referred to as "ambient targeting context," where the user identity information is already available in the application context (such as in session data or authentication context) but needs to be accessible to feature management evaluations throughout the application.
457+
458+
#### ITargetingContextAccessor
459+
460+
The library provides a solution through the `ITargetingContextAccessor` pattern.
461+
462+
``` typescript
463+
interface ITargetingContext {
464+
userId?: string;
465+
groups?: string[];
466+
}
467+
468+
interface ITargetingContextAccessor {
469+
getTargetingContext: () => ITargetingContext | undefined;
470+
}
471+
```
472+
473+
Instead of explicitly passing the targeting context with each `isEnabled` or `getVariant` call, you can provide a function that knows how to retrieve the current user's targeting information from your application's context:
474+
475+
```typescript
476+
import { FeatureManager, ConfigurationObjectFeatureFlagProvider } from "@microsoft/feature-management";
477+
478+
// Create a targeting context accessor that uses your application's auth system
479+
const targetingContextAccessor = {
480+
getTargetingContext: () => {
481+
// In a web application, this might access request context or session data
482+
// This is just an example - implement based on your application's architecture
483+
return {
484+
userId: getCurrentUserId(), // Your function to get current user
485+
groups: getUserGroups() // Your function to get user groups
486+
};
487+
}
488+
};
489+
490+
// Configure the feature manager with the accessor
491+
const featureManager = new FeatureManager(featureProvider, {
492+
targetingContextAccessor: targetingContextAccessor
493+
});
494+
495+
// Now you can call isEnabled without explicitly providing targeting context
496+
// The feature manager will use the accessor to get the current user context
497+
const isBetaEnabled = await featureManager.isEnabled("Beta");
498+
```
499+
500+
This pattern is particularly useful in server-side web applications where user context may be available in a request scope or in client applications where user identity is managed centrally.
501+
502+
#### Using AsyncLocalStorage for request context
503+
504+
One common challenge when implementing the targeting context accessor pattern is maintaining request context throughout an asynchronous call chain. In Node.js web applications, user identity information is typically available in the request object, but becomes inaccessible once you enter asynchronous operations.
505+
506+
Node.js provides [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage) from the `async_hooks` module to solve this problem. It creates a store that persists across asynchronous operations within the same logical "context" - perfect for maintaining request data throughout the entire request lifecycle.
507+
508+
Here's how to implement a targeting context accessor using AsyncLocalStorage in an express application:
509+
510+
```typescript
511+
import { AsyncLocalStorage } from "async_hooks";
512+
import express from "express";
513+
514+
const requestAccessor = new AsyncLocalStorage();
515+
516+
const app = express();
517+
// Middleware to store request context
518+
app.use((req, res, next) => {
519+
// Store the request in AsyncLocalStorage for this request chain
520+
requestAccessor.run(req, () => {
521+
next();
522+
});
523+
});
524+
525+
// Create targeting context accessor that retrieves user data from the current request
526+
const targetingContextAccessor = {
527+
getTargetingContext: () => {
528+
// Get the current request from AsyncLocalStorage
529+
const request = requestContext.getStore();
530+
if (!request) {
531+
return undefined; // Return undefined if there's no current request
532+
}
533+
// Extract user data from request (from session, auth token, etc.)
534+
return {
535+
userId: request.user?.id,
536+
groups: request.user?.groups || []
537+
};
538+
}
539+
};
540+
```
541+
452542
## Variants
453543

454544
When new features are added to an application, there may come a time when a feature has multiple different proposed design options. A common solution for deciding on a design is some form of A/B testing, which involves providing a different version of the feature to different segments of the user base and choosing a version based on user interaction. In this library, this functionality is enabled by representing different configurations of a feature with variants.
@@ -457,7 +547,7 @@ Variants enable a feature flag to become more than a simple on/off flag. A varia
457547

458548
### Getting a variant with targeting context
459549

460-
For each feature, a variant can be retrieved using the `FeatureManager`'s `getVariant` method. The variant assignment is dependent on the user currently being evaluated, and that information is obtained from the targeting context you passed in.
550+
For each feature, a variant can be retrieved using the `FeatureManager`'s `getVariant` method. The variant assignment is dependent on the user currently being evaluated, and that information is obtained from the targeting context you passed in. If you have registered a targeting context accessor to the `FeatureManager`, the targeting context will be automatically retrieved from it. But you can still override it by manually passing targeting context when calling `getVariant`.
461551

462552
```typescript
463553
const variant = await featureManager.getVariant("MyVariantFeatureFlag", { userId: "Sam" });
@@ -542,8 +632,8 @@ The process of allocating a feature's variants is determined by the `allocation`
542632

543633
```json
544634
"allocation": {
545-
"default_when_enabled": "Small",
546635
"default_when_disabled": "Small",
636+
"default_when_enabled": "Small",
547637
"user": [
548638
{
549639
"variant": "Big",
@@ -751,6 +841,32 @@ trackEvent(appInsights.defaultClient, "<TARGETING_ID>", {name: "TestEvent", pro
751841

752842
The telemetry publisher sends `FeatureEvaluation` custom events to the Application Insights when a feature flag enabled with telemetry is evaluated. The custom event follows the [FeatureEvaluationEvent](https://github.com/microsoft/FeatureManagement/tree/main/Schema/FeatureEvaluationEvent) schema.
753843

844+
### Targeting telemetry processor
845+
846+
If you have implemented [`ITargetingContextAccessor`](#itargetingcontextaccessor), you can use the built-in Application Insights telemetry processor to automatically attach targeting ID information to all telemetry by calling the `createTargetingTelemetryProcessor` function.
847+
848+
```typescript
849+
const appInsights = require("applicationinsights");
850+
appInsights.setup(process.env.APPINSIGHTS_CONNECTION_STRING).start();
851+
852+
const { createTargetingTelemetryProcessor } = require("@microsoft/feature-management-applicationinsights-node");
853+
appInsights.defaultClient.addTelemetryProcessor(
854+
createTargetingTelemetryProcessor(targetingContextAccessor)
855+
);
856+
```
857+
858+
This ensures that every telemetry item sent to Application Insights includes the user's targeting ID information (userId and groups), allowing you to correlate feature flag usage with specific users or groups in your analytics.
859+
860+
If you are using the targeting telemetry processor, instead of calling the `trackEvent` method provided by the feature management package, you can directly call the `trackEvent` method from the Application Insights SDK. The targeting ID information will be automatically attached to the custom event telemetry's `customDimensions`.
861+
862+
```typescript
863+
// Instead of calling trackEvent and passing the app insights client
864+
// trackEvent(appInsights.defaultClient, "<TARGETING_ID>", {name: "TestEvent", properties: {"Tag": "Some Value"}});
865+
866+
// directly call trackEvent method provided by App Insights SDK
867+
appInsights.defaultClient.trackEvent({ name: "TestEvent" });
868+
```
869+
754870
## Next steps
755871

756872
To learn how to use feature flags in your applications, continue to the following quickstarts.

articles/azure-app-configuration/feature-management-overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ Feature | .NET | Spring | Python | JavaScript
3939
------- | ---- | ------ | ------ | ----------
4040
Targeting Filter | [GA](./feature-management-dotnet-reference.md#targeting) | GA | [GA](./feature-management-python-reference.md#targeting) | [GA](./feature-management-javascript-reference.md#targeting)
4141
Targeting Exclusion | [GA](./feature-management-dotnet-reference.md#targeting-exclusion) | GA | [GA](./feature-management-python-reference.md#targeting-exclusion) | [GA](./feature-management-javascript-reference.md#targeting-exclusion)
42-
Ambient Targeting | [GA](./feature-management-dotnet-reference.md#targeting-in-a-web-application) | WIP | WIP | WIP
42+
Ambient Targeting | [GA](./feature-management-dotnet-reference.md#targeting-in-a-web-application) | WIP | WIP | [Preview](./feature-management-javascript-reference.md#targeting-in-a-web-application)
4343
Time Window Filter | [GA](./feature-management-dotnet-reference.md#microsofttimewindow) | GA | [GA](./feature-management-python-reference.md#microsofttimewindow) | [GA](./feature-management-javascript-reference.md#microsofttimewindow)
4444
Recurring Time Window | [GA](./feature-management-dotnet-reference.md#microsofttimewindow) | GA | WIP | WIP
4545
Custom Feature Filter | [GA](./feature-management-dotnet-reference.md#implementing-a-feature-filter) | GA | [GA](./feature-management-python-reference.md#implementing-a-feature-filter) | [GA](./feature-management-javascript-reference.md#implementing-a-feature-filter)

0 commit comments

Comments
 (0)