SDKs overview
feat ships first-party SDKs for the runtimes most teams use, plus OpenFeature providers. There are two evaluation models, split by where the code runs:
- Server SDKs evaluate locally. They poll the full datafile and run the evaluation engine in-process. Flag reads make no network call.
- Client SDKs evaluate remotely. Browser and mobile apps never receive the datafile (which contains your rules and segment definitions). Instead the SDK sends the context to feat’s edge, which evaluates and returns only the resolved values. The SDK caches those values so reads stay synchronous, and subscribes to a live stream so they update in near-real time.
The split exists for one reason: your targeting rules and segments are yours. A server you control can hold the whole datafile; an untrusted browser or phone should only ever see the answer, not the ruleset. See Evaluation model for the full picture.
Pick by runtime
Section titled “Pick by runtime”| Runtime | Package | Model | API key type |
|---|---|---|---|
| Node.js, Bun, Deno (server) | @feathq/js-sdk | Local | Server key (feat_sdk_…) |
| Go | github.com/feathq/go-sdk | Local | Server key (feat_sdk_…) |
| Python | feat-sdk | Local | Server key (feat_sdk_…) |
| Ruby | feat-sdk (gem) | Local | Server key (feat_sdk_…) |
| Browser JavaScript | @feathq/web-sdk | Remote | Client-side ID (feat_cs_…) |
| Flutter / Dart | feat_sdk | Remote | Client-side ID (feat_cs_…) or mobile key |
| Any web app using OpenFeature | @feathq/openfeature-web | Remote | Client-side ID (feat_cs_…) |
| Any Node.js app using OpenFeature | @feathq/js-sdk | Local | Server key (feat_sdk_…) |
| Any Dart app using OpenFeature | feat_openfeature | Remote | Client-side ID (feat_cs_…) or mobile key |
Server SDKs use a server key. Client SDKs use a public client-side ID or, for mobile, a mobile key.
What every SDK shares
Section titled “What every SDK shares”- Synchronous reads. Whether values come from a local datafile or a cached remote snapshot,
getBooleanValueand friends return in-process after the client is ready. No SDK blocks on the network at read time. - ETag-aware / version-aware polling. Unchanged datafiles return
304 Not Modified; unchanged evaluation snapshots are skipped by version. Default poll interval is 30 seconds; while a live stream is connected the poll relaxes to a slow safety-net cadence. - Live streaming. Client SDKs open a Server-Sent Events stream so a flag change or context change is reflected in milliseconds, and fire a
changeevent you can hook to re-render. - Identical semantics. The
@feathq/feat-evalpackage is the reference engine. Every SDK, local or remote, produces the same result for the same context, datafile, and flag key, regardless of language. - Same API shape. Every SDK exposes
getBooleanValue,getStringValue,getNumberValue,getObjectValue(and a richerevaluate/getDetailthat also returns the reason). The default-value-first argument order matches OpenFeature.
What differs
Section titled “What differs”- Local vs remote evaluation. Server SDKs hold the datafile and evaluate in-process. Client SDKs send the context to feat’s edge and cache the resolved values. Both read synchronously; only where the engine runs differs.
- Datafile exposure. Only server keys receive the datafile. Client keys never do, so rules and segment definitions stay on feat’s edge.
- OpenFeature coverage. The JavaScript family (web + Node.js) and Dart ship OpenFeature providers today. Go, Python, and Ruby expose the native API only; providers are planned.
OpenFeature
Section titled “OpenFeature”feat is compatible with OpenFeature, the CNCF standard for feature flags. If you use OpenFeature already, swap in the feat provider; if you do not, using OpenFeature is the route to stay vendor-portable. See OpenFeature.
Datafile format
Section titled “Datafile format”The wire format is documented at Datafile format. You only need this if you are writing a custom server SDK or a tool that consumes the file directly. Client SDKs never see it.
Reporting and metrics
Section titled “Reporting and metrics”feat does not store per-evaluation events or the contexts you evaluate against. Server SDKs evaluate entirely on your machine, so no context ever leaves it. Client SDKs send the context to feat’s edge to evaluate; feat counts the unique context toward your monthly active users (MAU) but does not persist the context or the evaluation. If you need to count exposures or correlate with your analytics tool, hook the SDK’s change event (or wrap the evaluate call) and push events to your own pipeline.