You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/node-sdk/README.md
+52-81Lines changed: 52 additions & 81 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,10 +59,6 @@ You can also [use the HTTP API directly](https://docs.reflag.com/api/http-api)
59
59
To get started you need to obtain your secret key from the [environment settings](https://app.reflag.com/env-current/settings/app-environments)
60
60
in Reflag.
61
61
62
-
> [!CAUTION]
63
-
> Secret keys are meant for use in server side SDKs only. Secret keys offer the users the ability to obtain
64
-
> information that is often sensitive and thus should not be used in client-side applications.
65
-
66
62
Reflag will load settings through the various environment variables automatically (see [Configuring](#configuring) below).
67
63
68
64
1. Find the Reflag secret key for your development environment under [environment settings](https://app.reflag.com/env-current/settings/app-environments) in Reflag.
@@ -91,7 +87,7 @@ Once the client is initialized, you can obtain flags along with the `isEnabled`
91
87
status to indicate whether the flag is targeted for this user/company:
92
88
93
89
> [!IMPORTANT]
94
-
> If `user.id`or `company.id`is not given, the whole `user`or`company` object is ignored.
90
+
> If `user.id` is not given, the whole `user`object is ignore. Similarly, without `company.id` the`company` object is ignored.
`flagsFallbackProvider` is a reliability feature that lets the SDK persist the latest successfully fetched raw flag definitions to fallback storage such as a local file, Redis, S3, GCS, or a custom backend.
205
201
202
+
> [!NOTE]
203
+
>
204
+
> `fallbackFlags` is deprecated. Prefer `flagsFallbackProvider` for startup fallback and outage recovery.
205
+
> `flagsFallbackProvider` is not used in offline mode.
206
+
206
207
#### How it works
207
208
208
209
Reflag servers remain the primary source of truth. On `initialize()`, the SDK always tries to fetch a live copy of the flag definitions first, and it continues refreshing those definitions from the Reflag servers over time.
@@ -240,48 +241,50 @@ You can access the built-in providers through the `fallbackProviders` namespace:
240
241
-`fallbackProviders.s3(...)`
241
242
-`fallbackProviders.gcs(...)`
242
243
243
-
##### File provider
244
+
##### Static provider
245
+
246
+
If you just want a fixed fallback copy of simple enabled/disabled flags, you can provide a static map:
The file provider stores one snapshot file per environment in the configured
280
+
`directory`.
281
+
281
282
##### Redis provider
282
283
283
284
The built-in Redis provider creates a Redis client automatically when omitted and uses `REDIS_URL` from the environment. It stores snapshots under the configured `keyPrefix` and uses the first 16 characters of the secret key hash in the Redis key.
284
285
286
+
Without a `keyPrefix` set, it will default to to the key `reflag:flags-fallback:${secretKeyHash}`.
The built-in S3 provider works out of the box using the AWS SDK's default credential chain and region resolution. It stores the snapshot object under the configured `keyPrefix` and uses a hash of the secret key in the object name.
299
302
303
+
Without a `keyPrefix` set, it will default to path `reflag/flags-fallback/${secretKeyHash}`.
The built-in GCS provider works out of the box using Google Cloud's default application credentials. It stores the snapshot object under the configured `keyPrefix` and uses a hash of the secret key in the object name.
316
321
322
+
Without a `keyPrefix` set, it will default to path `reflag/flags-fallback/${secretKeyHash}`.
To test fallback startup in your own app, first run it once with a working Reflag connection so a snapshot is saved. Then restart it with the same secret key and fallback provider configuration, but set `apiBaseUrl` to `http://127.0.0.1:65535`. That forces the live fetch to fail and lets you verify that the SDK initializes from the saved snapshot instead.
339
+
To test fallback startup in your own app, first run it once with a working Reflag connection so a snapshot is saved. Then restart it with the same secret key and fallback provider configuration, but set `apiBaseUrl`(or set the `REFLAG_API_BASE_URL` environment variable) to `http://127.0.0.1:65535`. That forces the live fetch to fail and lets you verify that the SDK initializes from the saved snapshot instead.
333
340
334
341
#### Writing a custom provider
335
342
336
-
If you just want a fixed fallback copy of the flag definitions, a custom provider can be very small:
343
+
If you just store definitions in your database or similar, a custom provider can be very small:
// optionally, look up the snapshot using the context.secretKeyHash as a key
355
+
returnsnapshot;
362
356
},
363
357
364
-
async save() {
365
-
// no-op
358
+
async save(context, snapshot) {
359
+
const serialized =JSON.stringify(snapshot);
360
+
// write serialized snapshot to database, optionally using context.secretKeyHash as a key
366
361
},
367
362
};
368
363
```
369
364
370
-
> [!NOTE]
371
-
>
372
-
> `fallbackFlags` is deprecated. Prefer `flagsFallbackProvider` for startup fallback and outage recovery.
373
-
> `flagsFallbackProvider` is not used in offline mode.
374
-
375
365
## Bootstrapping client-side applications
376
366
377
367
The `getFlagsForBootstrap()` method is useful whenever you need to pass flag data to another runtime or serialize it without wrapper functions. Server-side rendering (SSR) is a common example, but it is also useful for other bootstrapping and hydration flows.

668
658
669
-
## Testing
659
+
## Testing with flag overrides
670
660
671
-
When writing tests that cover code with flags, you can toggle flags on/off programmatically to test different behavior. For tests, you will often want to run the client in offline mode and provide flag overrides directly through the client options.
661
+
When writing tests that cover code with flags, you can toggle flags on/off programmatically to test different behavior. For tests, you will often want to run the client in offline mode:
672
662
673
663
`reflag.ts`:
674
664
@@ -680,7 +670,11 @@ export const reflag = new ReflagClient({
680
670
});
681
671
```
682
672
683
-
You can then set base overrides for a test run by passing `flagOverrides` in the constructor, replacing them later with `setFlagOverrides()`, or clearing them with `clearFlagOverrides()`:
673
+
There are a few ways to programmatically manipulate the overrides which are appropriate when testing:
674
+
675
+
### Base overrides
676
+
677
+
You can set base overrides for a test run by passing `flagOverrides` in the constructor, replacing them later with `setFlagOverrides()` and clearing them with `clearFlagOverrides()`:
684
678
685
679
```typescript
686
680
// pass directly in the constructor
@@ -719,6 +713,8 @@ describe("API Tests", () => {
719
713
});
720
714
```
721
715
716
+
### Layering overrides
717
+
722
718
`pushFlagOverrides()` serves a different purpose: it adds a temporary layer on top of the base overrides and returns a remove function that removes only that layer. This is useful for nested tests:
723
719
724
720
```typescript
@@ -755,7 +751,9 @@ The precedence is:
755
751
756
752
If the same flag is set in both places, the pushed override wins until its remove function is called.
757
753
758
-
`pushFlagOverrides()` also accepts a function if the temporary override depends on the evaluation context:
754
+
### Context dependent overrides
755
+
756
+
`setFlagOverrides()` and `pushFlagOverrides()` also accept a function if the override depends on the evaluation context:
Flag overrides allow you to override flags and their configurations locally. This is particularly useful when testing changes locally, for example when running your app and clicking around to verify behavior before deploying your changes.
768
+
### Additional ways to provide flag overrides
773
769
774
-
For automated tests, see the [Testing](#testing) section above.
775
-
776
-
When testing locally during development, you also have these additional ways to provide overrides:
770
+
You also have these additional ways to provide overrides, which can be helpful when testing out locally:
In addition to local flag evaluation, Reflag supports remote evaluation using stored context. This is useful when you want to evaluate flags using user/company attributes that were previously sent to Reflag:
0 commit comments