See the feature flag in action

Finally, we will query both products and products-fs to see our flag in action. Use either the playground or the CLI.

Before and after

Open the local playground at http://localhost:3002 .

Remove all Headers, and run:

1
2
3
4
5
6
7

Error expected: Because we have not yet added the correct header or cookie for the feature flag, the following response (or similar) is expected:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Add the Header

HeaderValue
X-Feature-FlagName of the feature flag

In Headers, set:

1
2
3

Then run again:

1
2
3
4
5
6
7

You should see productCount resolve (for example 5 for an employee with five products).

HeaderValue
Cookiefeature_flag={name of the feature flag}

A cookie works too, in the format feature_flag=<flag-name>. This is handy in a browser, where setting a cookie is often easier than a custom header.

In Headers, set:

1
2
3

Run the same EmployeeProductsWithCount query. You should get the same productCount result.

Using the CLI

1
2
3
4
5
6
7
8
9
10
1
2
3
4
5
6
7
8
9
10

Precedence and fallback

Two rules to remember:

Header wins. If both the X-Feature-Flag header and the feature_flag cookie are present, the header takes precedence.

Invalid flags fall back silently. If you pass a flag name that does not exist, the router serves the base supergraph rather than erroring on the flag. Try it:

1
2
3
4
5

The products-only query still works; a query for productCount would fail because you fell back to the base schema.

When the header or cookie is omitted, clients get the base (non-feature-flag) supergraph: exactly as before you created the flag.

Task

Knowledge check

If both the X-Feature-Flag header and the feature_flag cookie are set, which one is used?

What happens when you pass a flag name that does not exist?

PreviousNext