DEV Community: Dencio

Checkgate: Feature Flags That Don't Cost You a Network Round-Trip

Dencio — Wed, 22 Jul 2026 01:57:02 +0000

An open-source, self-hosted feature flag engine that evaluates flags in-process (sub-microsecond) and syncs every SDK over SSE in under 50ms. Built in Rust, with native SDKs for Node, Web, React Native, and Flutter.

Every feature-flag SaaS I've used shares the same architecture: your code calls isEnabled(), that call goes over the network to their servers, and you wait 5–50ms for an answer. It's fast enough that nobody complains in a demo, and slow enough that it shows up the moment you put a flag check in a hot path, an edge function, or a mobile app on a bad connection.

So I built Checkgate — a self-hosted, open-source feature flag engine that flips the model: flags are evaluated in-process, in local memory, with no network call on the hot path. The server's only job is to push changes to every connected SDK the moment they happen.

![A flag change flows from the dashboard to the Checkgate server, which pushes it over SSE to every SDK, where flags evaluate locally in-process.]

The core idea

Most flag services treat evaluation as a remote procedure call. Checkgate treats it as a local cache lookup that happens to stay in sync in real time:

Your app boots and the SDK opens one persistent SSE connection to the Checkgate server.
The server bootstraps it with the full flag set for that environment.
From then on, every isEnabled() is a pure, in-memory function call — no I/O, no allocations on the hot path.
When someone flips a flag in the dashboard, the server pushes the delta over SSE, and every connected SDK instance is updated within ~50ms.

┌──────────────────────┐          SSE push, <50ms          ┌─────────┐
│  Checkgate Server     │ ───────────────────────────────▶ │ Node SDK │
│  (Rust + Postgres +   │ ───────────────────────────────▶ │ Web SDK  │
│   Redis pub/sub)      │ ───────────────────────────────▶ │ RN SDK   │
└──────────────────────┘                                    └─────────┘
                                                          isEnabled() = ~100ns, local

The evaluation core (checkgate-core) is a Rust library compiled to different targets depending on the platform:

Platform	Binding	Artifact
Node.js	NAPI-RS	native `.node` addon
Browser	wasm-bindgen	`.wasm` + JS glue
React Native	JSI (C FFI)	`.so` / `.dylib`
Flutter	`dart:ffi`	`.so` / `.dylib`

Same Rust logic everywhere. No re-implemented rule engine per platform, no drift between what your Node backend decides and what your mobile app decides for the same user.

It's not just a boolean toggle store

A flag in Checkgate can be a boolean, string, integer, or JSON value, and evaluation runs through a well-defined pipeline:

isEnabled(flag_key, user_key, attributes)
    │
    ├── Prerequisites unsatisfied  → false  (checked first, fails closed)
    ├── Flag not found             → false
    ├── flag.is_enabled == false   → false
    │
    ├── Targeting rules (first match wins)
    │   └── rule.attribute ∈ attributes AND operator matches → true
    │
    └── Rollout percentage
        ├── 0%   → false
        ├── 100% → true
        └── MurmurHash3(flag_key + ":" + user_key) % 100 < pct → true/false

A few things that fall out of that:

Targeting rules (equals, contains, starts_with, greater_than, etc.) always win over rollout percentage — so you can ship a feature at 5% globally while your whole team sees it via an email ends_with @yourcompany.com rule.
Rollout percentage uses deterministic MurmurHash3 bucketing: the same user always lands in the same bucket, so bumping 10% → 20% only adds new users, it never reshuffles the cohort you already have.
Segments let you define an audience ("Internal Employees", "Beta Users") once and reference it from any flag by key — they're expanded server-side, so SDKs never need to know segments exist.
Prerequisite flags let one flag depend on another being enabled (or resolved to a specific value), evaluated recursively with a depth limit that fails closed on cycles.
Weighted variants turn a flag into an A/B/n split — a 60/30/10 traffic split across control / treatment-a / treatment-b — using the same sticky hashing approach, salted independently so variant assignment doesn't correlate with the rollout gate.

All of that lives entirely in the flag payload the SDK already has locally. No extra round-trip for a targeting decision, ever.

Governance, because "who changed this flag in prod" is a real question

Once more than one person can touch a flag, you need more than a toggle:

RBAC — admin / editor / viewer, per project, independent of workspace-level admin.
Change-request approvals — require a second reviewer before a change takes effect in sensitive environments; self-approval is blocked.
Audit log of every change, plus scheduled changes and a cross-environment diff with one-click promote.
Personal access tokens, scoped and revocable, as an alternative to handing out admin-equivalent SDK keys to CI/CD.
Slack & Microsoft Teams alerts — flag and change-request activity land in a channel with native formatting (Block Kit for Slack, MessageCard for Teams), subscribable per event type (flag.updated, change_request.rejected, etc.).

The ecosystem

The server and SDKs are the core, but the parts that made Checkgate feel finished for real infrastructure are the boring-but-essential pieces:

@checkgate/ssr — server-render initial flag state for Next.js/Remix/SvelteKit and hydrate with zero flag flicker.
@checkgate/edge — a zero-dependency, runtime-agnostic evaluator for Cloudflare Workers / Fly.io that pulls a flag snapshot, caches it with TTL + stale-while-revalidate, and fails open on origin outages — delegating actual evaluation to the same WASM core every other SDK uses.
@checkgate/cli — checkgate typegen generates type-safe flag accessors for TypeScript, Dart, and Rust, so a typo'd flag key is a compile error instead of a silent false.
Terraform / OpenTofu provider and a Kubernetes operator (FeatureFlag CRD) for managing flags as code, with drift correction and require_approval awareness.

Try it

docker run -d -p 3000:3000 ghcr.io/thinkgrid-labs/checkgate:latest

That single command pulls the published, multi-arch (amd64/arm64) all-in-one image — PostgreSQL, Redis, the Checkgate server, and the dashboard bundled together, no build step, no clone. Finish the setup wizard at localhost:3000/setup, grab the auto-generated SDK key, and:

import { CheckgateClient } from '@checkgate/node'

const client = new CheckgateClient({
  serverUrl: 'http://localhost:3000',
  sdkKey: 'sk_live_your_key_here',
})

await client.connect()

const enabled = client.isEnabled('new-checkout-flow', 'user-123', {
  email: 'alice@example.com',
  plan: 'pro',
})

The client connects once, downloads the flag set, and every subsequent isEnabled() is local. That's the whole pitch.

Why self-host this instead of paying per-seat

If you've priced out LaunchDarkly or Statsig at scale, the pitch for a self-hosted alternative is usually cost. The pitch for Checkgate specifically is:

Evaluation latency goes from "network call" to "~100ns," which matters if you're flag-checking inside a request hot path, an edge worker, or a mobile app.
Your user attributes never leave your infra — targeting attributes are evaluated locally and are never sent to the server, which matters if you have data-residency constraints.
No vendor lock-in — it's Apache 2.0, single Rust binary + Postgres + Redis, and you can read every line of the evaluation logic that decides what your users see.

It's still early — the roadmap includes a warehouse-export path and the A/B testing significance calculations are in beta — but the core (evaluation, SSE propagation, targeting, rollouts, governance) is solid enough to run in production today.

Repo: https://github.com/ThinkGrid-Labs/checkgate
Docs: https://thinkgrid-labs.github.io/checkgate

If you try it, I'd genuinely like to hear where it breaks — issues and PRs are welcome.

Your app has two caches. What if it only needed one?

Dencio — Sun, 19 Jul 2026 04:56:23 +0000

Redis on the server, some state library in the browser, and a pile of hand-written sync between them. I got tired of writing that layer, so I built a cache engine that compiles to both native and WebAssembly.

Every app I've worked on ends up with the same shape.

There's a cache on the server — Redis, usually. And there's state in the browser — Zustand, Redux, React Query, whatever. Between them sits a layer nobody designed on purpose: fetchedAt timestamps, staleness checks, an invalidation call you have to remember to make after every mutation, and a polling interval you tuned once and never revisited.

That layer is where the bugs live. The cart total that's stale for four seconds. The feature flag that flipped in the dashboard but not in the tab that's already open. The counter that goes backwards because two tabs raced.

The frustrating part is that both halves are caches. They store keys, they expire things, they invalidate. We just built them out of completely different parts and then wrote glue to keep them agreeing.

What if it were literally the same cache?

That's the question behind Recached.

It's a cache server written in Rust that speaks RESP — the Redis wire protocol — on port 6379. Your existing client works unchanged:

import Redis from 'ioredis';
const cache = new Redis('redis://127.0.0.1:6379');
await cache.set('inventory:item:99', '42');

That part is unremarkable. Here's the part that isn't.

The evaluation engine — the thing that actually stores keys, applies TTLs, and evaluates commands — is a single Rust crate with no networking and no file I/O. It compiles to native for the server and to wasm32 for the browser. Same source, same semantics, both sides.

A WebSocket sync layer keeps them in step. So the browser doesn't call the cache. The browser is a cache, holding a live replica.

import { createCache } from 'recached-edge';

const cache = await createCache({
  persistence: true,                        // survives refresh via IndexedDB
  connect: { url: 'ws://127.0.0.1:6380' },  // syncs with the server
});

cache.get('inventory:item:99'); // "42" — from local WASM memory

That read doesn't touch the network. It's a lookup in a hash map that happens to be inside your browser tab.

What that changes

Reads stop being async problems. No loading state for data you already have. No stale-while-revalidate dance. The value is in memory or it isn't.

Pushes replace polling. A server-side write fans out over the WebSocket and lands in every connected browser's local copy. In React:

const cart = useKeys('cart:item:*'); // current state + live updates

No /api/cart endpoint. No interval. No socket handler you wrote by hand.

Offline stops being a special case. Writes made while disconnected apply locally and queue in an IndexedDB-backed outbox. On reconnect the client re-authenticates, re-subscribes, and replays. Because operations replay rather than final values, merges follow the data type — two clients incrementing the same counter both land, instead of one clobbering the other.

Tabs agree for free. Cross-tab sync goes over BroadcastChannel, no server round-trip.

The honest part

I'd rather you evaluate this accurately than be surprised later.

The server is in good shape for cache workloads: snapshots and AOF persistence, replication with automatic single-replica failover, TLS, constant-time auth, hardened parsers, and a load/chaos suite in CI.

The browser sync layer is beta. The invariants are specified and tested end to end, but the code is young and hasn't had a third-party security review. Concretely: don't expose the sync port to untrusted multi-tenant traffic until you've read the sync-scopes documentation and understand the model.

On performance — pipelined, it's ahead of Redis on 6 of 7 commands, because it's multi-threaded where Redis executes on one core. Unpipelined it runs at 46–96% of Redis depending on the command; HSET in particular is a known outlier I'm still working on. The full table, including every case where it loses, is published in the docs. The goal was never to beat Redis at being Redis — it's to delete the network hop for client reads, which no server-side cache can do.

Where it isn't the right tool: if nothing but your own backend reads the cache, use Redis. It's more mature, has more data structures, and solves that problem completely. Recached earns its place when a browser, mobile app, or edge worker needs the same data your backend writes.

Try it

docker run -p 6379:6379 -p 6380:6380 ghcr.io/thinkgrid-labs/recached:latest
npm install recached-edge

Docs: recached.dev · Source: github.com/thinkgrid-labs/recached · Apache 2.0

Also in the box: a native JSON type with path updates and RFC 7386 merge, sliding-window rate limiting as a first-class command, live queries, and primary/replica replication.

If you've built that sync layer by hand — and I think most of us have — I'd genuinely like to hear which part broke for you. That's the part I most want to get right.

Local-First Vectors: How to Build Privacy-Preserving AI Apps without the Cloud

Dencio — Fri, 10 Apr 2026 11:32:37 +0000

The Missing Piece for On-Device AI

The world of AI is moving to the edge. With the rise of on-device models like Transformers.js, Gemma, and Phind, we are closer than ever to a truly "dark" application architecture—one where zero data leaves the user's device.

However, there’s a paradox: while we have the models running on-device, we are still sending our sensitive data to cloud-based vector databases like Pinecone or Weaviate to perform similarity searches.

I wanted to solve this paradox.

I’ve been building TalaDB: an open-source, local-first document and vector database built in Rust that runs identically across the Browser (WASM), Node.js, and React Native.

The Multi-Platform Problem

If you've ever tried to build a cross-platform, local-first app, you know the pain:

Developing for the browser? You're likely stuck with IndexedDB or a complex WASM-SQL setup.
Developing for Mobile? You're probably using SQLite.
Developer Experience (DX) Hell: Managing separate drivers, binary extensions for vector search (sqlite-vss), and split business logic is a nightmare.

I wanted a single, unified API. One core to rule them all.

Introducing TalaDB: A Unified Engine

TalaDB provides a familiar, MongoDB-like API for both document filtering and vector similarity search. Whether you are in a React Native app or a Chrome SharedWorker, the code looks exactly the same:

const results = await articles.findNearest('embedding', query, 5, {
  category: 'support',
  locale: 'en',
});

One call. Metadata filter + Vector ranking. No cloud round-trips.

Deep Dive: Under the Hood

Why Rust + redb?

I chose a pure-Rust architecture because of the safety and performance guarantees. For the storage engine, I use redb—a high-performance B-tree store that provides ACID transactions without the overhead of a full SQL engine.

WASM + OPFS: The Bleeding Edge

In the browser, TalaDB leverages the Origin Private File System (OPFS). By running the database inside a SharedWorker, I can achieve near-native performance while keeping the main UI thread completely free.

Binary Compactness

By using postcard for binary serialization, TalaDB keeps data footprints extremely small—often smaller and faster than traditional JSON-based stores. The entire WASM bundle is sub-400KB.

Practical Example: Offline Semantic Search

Imagine building a support app that works 100% offline. Here is how you'd handle a hybrid query:

import { openDB } from 'taladb';

const db = await openDB('docs.db');
const articles = db.collection('articles');

// Find the 5 most relevant articles for a given embedding
const results = await articles.findNearest('embedding', userVector, 5);

results.forEach(({ document, score }) => {
  console.log(`[${score.toFixed(2)}] ${document.title}`);
});

The Future of Local-First

TalaDB is currently in Alpha (v0.3.0). My goal is to bridge the gap between human privacy and machine-learning intelligence.

I’m currently focused on:

⚡ Further optimizations for React Native JSI.
📡 Adding atomic sync and multi-user capabilities.
🧠 Expanding the query operator library.

TalaDB is open-source and MIT licensed. I’d love for you to try the alpha, give me some feedback, or even give the project a star if you find it useful.

Links: