Feature flag SDK

Client SDK

Ships in @accelerup-llc/web-monitor (v0.7.0+), so a page with the monitoring SDK evaluates flags without a second dependency.

import { flags } from '@accelerup-llc/web-monitor';

await flags.init({
  ingestUrl: 'https://monitoring.qrdev.org/ingest',
  key: 'YOUR_INGEST_KEY',
  subject: { id: user.id, plan: user.plan, country: user.country },
});

if (flags.isOn('new-checkout')) { … }
const variant = flags.variant('checkout-layout');   // 'a' | 'b'
const config  = flags.json('pricing-rules');        // typed value

Bulk resolve

/resolve evaluates every flag for a subject in one request.

SSR bootstrap

Server-side rendering can resolve flags and pass them into the client as bootstrap data, so the first render already has the right values.

Without it, a flagged component renders the default, then flips — which is a visible flash and, for a layout flag, a layout shift that counts against CLS.

Server-side evaluation

Backend services call /resolve with the subject. Same evaluation, same answers, so a flag cannot disagree between the API and the page rendering its result.

The Cloudflare edge worker

Flags can be evaluated at the Cloudflare edge, which removes the round trip entirely for a page that only needs a handful.

Exposure tracking

When a subject is exposed to a variant, the SDK records it via /ingest/ab-uniques. Exposure — not page views — is the denominator every experiment result is computed against.

Caching and staleness

The SDK caches the resolved set and refreshes periodically. A flag flip propagates within the refresh interval.

If you need a flag to be a genuine kill switch, set a short refresh for that page and test the real path — measure how long it takes for a running client to see the change.

GitHub flag scan

AccelerUp scans repositories for flag usages, so a flag can be checked for references before it is deleted.