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
This PR adds Cloudflare Worker support to the Node SDK by introducing an
edge-optimized cache strategy, updating the client to select between
cache strategies, and providing example configurations and
documentation.
- Introduce inRequestCache and rename the existing cache to
periodicallyUpdatingCache
- Add EdgeClient class with "in-request" cache strategy and update
BucketClient to choose based on cacheStrategy
- Supply Cloudflare Worker examples, configuration files, and update
documentation
To use the Bucket NodeSDK with Cloudflare workers, set the `node_compat` flag [in your wrangler file](https://developers.cloudflare.com/workers/runtime-apis/nodejs/#get-started).
213
+
214
+
Instead of using `BucketClient`, use `EdgeClient` and make sure you call `ctx.waitUntil(bucket.flush());` before returning from your worker function.
215
+
216
+
```typescript
217
+
import { EdgeClient } from"@bucketco/node-sdk";
218
+
219
+
// set the BUCKET_SECRET_KEY environment variable or pass the secret key in the constructor
// initialize the client and wait for it to complete
225
+
// if the client was initialized on a previous invocation, this is a no-op.
226
+
awaitbucket.initialize();
227
+
const features =bucket.getFeatures({
228
+
user: { id: "userId" },
229
+
company: { id: "companyId" },
230
+
});
231
+
232
+
// ensure all events are flushed and any requests to refresh the feature cache
233
+
// have completed after the response is sent
234
+
ctx.waitUntil(bucket.flush());
235
+
236
+
returnnewResponse(
237
+
`Features for user ${userId} and company ${companyId}: ${JSON.stringify(features, null, 2)}`,
238
+
);
239
+
},
240
+
};
241
+
```
242
+
243
+
See [examples/cloudflare-worker](examples/cloudflare-worker/src/index.ts) for a deployable example.
244
+
245
+
Bucket maintains a cached set of feature definitions in the memory of your worker which it uses to decide which features to turn on for which users/companies.
246
+
247
+
The SDK caches feature definitions in memory for fast performance. The first request to a new worker instance fetches definitions from Bucket's servers, while subsequent requests use the cache. When the cache expires, it's updated in the background. `ctx.waitUntil(bucket.flush())` ensures completion of the background work, so response times are not affected. This background work may increase wall-clock time for your worker, but it will not measurably increase billable CPU time on platforms like Cloudflare.
248
+
210
249
## Error Handling
211
250
212
251
The SDK is designed to fail gracefully and never throw exceptions to the caller. Instead, it logs errors and provides
@@ -307,14 +346,14 @@ a configuration file on disk or by passing options to the `BucketClient`
307
346
constructor. By default, the SDK searches for `bucketConfig.json` in the
|`secretKey`| string | The secret key used for authentication with Bucket's servers. | BUCKET_SECRET_KEY |
313
-
|`logLevel`| string | The log level for the SDK (e.g., `"DEBUG"`, `"INFO"`, `"WARN"`, `"ERROR"`). Default: `INFO`| BUCKET_LOG_LEVEL |
314
-
|`offline`| boolean | Operate in offline mode. Default: `false`, except in tests it will default to `true` based off of the `TEST` env. var. | BUCKET_OFFLINE |
315
-
|`apiBaseUrl`| string | The base API URL for the Bucket servers. | BUCKET_API_BASE_URL |
316
-
|`featureOverrides`| Record<string, boolean> | An object specifying feature overrides for testing or local development. See [example/app.test.ts](https://github.com/bucketco/bucket-javascript-sdk/tree/main/packages/browser-sdk/example/app.test.ts) for how to use `featureOverrides` in tests. | BUCKET_FEATURES_ENABLED, BUCKET_FEATURES_DISABLED |
317
-
|`configFile`| string | Load this config file from disk. Default: `bucketConfig.json`| BUCKET_CONFIG_FILE |
|`secretKey`| string | The secret key used for authentication with Bucket's servers. | BUCKET_SECRET_KEY |
352
+
|`logLevel`| string | The log level for the SDK (e.g., `"DEBUG"`, `"INFO"`, `"WARN"`, `"ERROR"`). Default: `INFO`| BUCKET_LOG_LEVEL |
353
+
|`offline`| boolean | Operate in offline mode. Default: `false`, except in tests it will default to `true` based off of the `TEST` env. var. | BUCKET_OFFLINE |
354
+
|`apiBaseUrl`| string | The base API URL for the Bucket servers. | BUCKET_API_BASE_URL |
355
+
|`featureOverrides`| Record<string, boolean> | An object specifying feature overrides for testing or local development. See [examples/express/app.test.ts](https://github.com/bucketco/bucket-javascript-sdk/tree/main/packages/node-sdk/examples/express/app.test.ts) for how to use `featureOverrides` in tests. | BUCKET_FEATURES_ENABLED, BUCKET_FEATURES_DISABLED |
356
+
|`configFile`| string | Load this config file from disk. Default: `bucketConfig.json`| BUCKET_CONFIG_FILE |
318
357
319
358
> [!NOTE] > `BUCKET_FEATURES_ENABLED` and `BUCKET_FEATURES_DISABLED` are comma separated lists of features which will be enabled or disabled respectively.
See [example/app.ts](https://github.com/bucketco/bucket-javascript-sdk/tree/main/packages/node-sdk/example/app.ts) for a full example.
658
+
See [examples/express/app.ts](https://github.com/bucketco/bucket-javascript-sdk/tree/main/packages/node-sdk/example/express/app.ts) for a full example.
620
659
621
660
## Remote flag evaluation with stored context
622
661
@@ -687,11 +726,8 @@ these functions.
687
726
688
727
## Flushing
689
728
690
-
It is highly recommended that users of this SDK manually call `flush()`
691
-
method on process shutdown. The SDK employs a batching technique to minimize
692
-
the number of calls that are sent to Bucket's servers. During process shutdown,
693
-
some messages could be waiting to be sent, and thus, would be discarded if the
694
-
buffer is not flushed.
729
+
BucketClient employs a batching technique to minimize the number of calls that are sent to
730
+
Bucket's servers.
695
731
696
732
By default, the SDK automatically subscribes to process exit signals and attempts to flush
697
733
any pending events. This behavior is controlled by the `flushOnExit` option in the client configuration:
@@ -704,17 +740,6 @@ const client = new BucketClient({
704
740
});
705
741
```
706
742
707
-
> [!NOTE]
708
-
> If you are creating multiple client instances in your application, it's recommended to disable `flushOnExit`
709
-
> to avoid potential conflicts during process shutdown. In such cases, you should implement your own flush handling.
710
-
711
-
When you bind a client to a user/company, this data is matched against the
712
-
targeting rules. To get accurate targeting, you must ensure that the user/company
713
-
information provided is sufficient to match against the targeting rules you've
714
-
created. The user/company data is automatically transferred to Bucket. This ensures
715
-
that you'll have up-to-date information about companies and users and accurate
716
-
targeting information available in Bucket at all time.
717
-
718
743
## Tracking custom events and setting custom attributes
719
744
720
745
Tracking allows events and updating user/company attributes in Bucket.
0 commit comments