Skip to content

Commit a3314e4

Browse files
committed
update docs
1 parent 239ab9f commit a3314e4

2 files changed

Lines changed: 48 additions & 26 deletions

File tree

packages/node-sdk/README.md

Lines changed: 42 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ Bucket supports feature toggling, tracking feature usage, collecting feedback on
66

77
## Installation
88

9-
Install using your favourite package manager:
9+
Install using your favorite package manager:
1010

1111
{% tabs %}
1212
{% tab title="npm" %}
@@ -207,6 +207,45 @@ const featureDefs = await client.getFeatureDefinitions();
207207
// }]
208208
```
209209

210+
## Edge-runtimes like Cloudflare Workers
211+
212+
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
220+
const bucket = new EdgeClient();
221+
222+
export default {
223+
async fetch(request, _env, ctx): Promise<Response> {
224+
// 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+
await bucket.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+
return new Response(
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+
210249
## Error Handling
211250

212251
The SDK is designed to fail gracefully and never throw exceptions to the caller. Instead, it logs errors and provides
@@ -636,11 +675,8 @@ these functions.
636675
637676
## Flushing
638677
639-
It is highly recommended that users of this SDK manually call `flush()`
640-
method on process shutdown. The SDK employs a batching technique to minimize
641-
the number of calls that are sent to Bucket's servers. During process shutdown,
642-
some messages could be waiting to be sent, and thus, would be discarded if the
643-
buffer is not flushed.
678+
BucketClient employs a batching technique to minimize the number of calls that are sent to
679+
Bucket's servers.
644680
645681
By default, the SDK automatically subscribes to process exit signals and attempts to flush
646682
any pending events. This behavior is controlled by the `flushOnExit` option in the client configuration:
@@ -653,17 +689,6 @@ const client = new BucketClient({
653689
});
654690
```
655691
656-
> [!NOTE]
657-
> If you are creating multiple client instances in your application, it's recommended to disable `flushOnExit`
658-
> to avoid potential conflicts during process shutdown. In such cases, you should implement your own flush handling.
659-
660-
When you bind a client to a user/company, this data is matched against the
661-
targeting rules. To get accurate targeting, you must ensure that the user/company
662-
information provided is sufficient to match against the targeting rules you've
663-
created. The user/company data is automatically transferred to Bucket. This ensures
664-
that you'll have up-to-date information about companies and users and accurate
665-
targeting information available in Bucket at all time.
666-
667692
## Tracking custom events and setting custom attributes
668693
669694
Tracking allows events and updating user/company attributes in Bucket.

packages/node-sdk/src/edgeClient.ts

Lines changed: 6 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,11 @@
11
import { BucketClient } from "./client";
22
import { ClientOptions } from "./types";
33

4+
type EdgeClientOptions = Omit<
5+
ClientOptions,
6+
"cacheStrategy" | "flushIntervalMs" | "batchOptions"
7+
>;
8+
49
/**
510
* The EdgeClient is BucketClient pre-configured to be used in edge runtimes, like
611
* Cloudflare Workers.
@@ -20,21 +25,13 @@ import { ClientOptions } from "./types";
2025
* ```
2126
*/
2227
export class EdgeClient extends BucketClient {
23-
constructor(
24-
options: Omit<
25-
ClientOptions,
26-
"cacheStrategy" | "flushIntervalMs" | "batchOptions" | "refetchInterval"
27-
> & {
28-
cacheTTLMs?: number;
29-
} = {},
30-
) {
28+
constructor(options: EdgeClientOptions = {}) {
3129
const opts = {
3230
...options,
3331
cacheStrategy: "in-request" as const,
3432
batchOptions: {
3533
intervalMs: 0,
3634
},
37-
refetchInterval: options.cacheTTLMs,
3835
};
3936
super(opts);
4037
}

0 commit comments

Comments
 (0)