DEV Community: Dencio

Your realtime UI can lie to you, and nothing logs it

Dencio — Tue, 18 Aug 2026 10:31:58 +0000

Most web apps poll. A client asks the server every few seconds whether anything changed, and almost every time the answer is no. A dashboard on a five-second interval costs 720 requests an hour, per tab, to mostly learn nothing — and it's still seconds behind reality.

So you go looking for push. And you find that every option charges a tax that has very little to do with pushing.

The tax

Standalone hubs — Mercure, Centrifugo — are a second service to deploy, monitor, and keep alive. Worse: that service has never seen your user table. Because it can't answer "may this person read this?", you have to build a whole authorization subsystem before one message flows. Minting tokens, scoping them to topics, expiry, rotation, revocation. That subsystem is usually the largest part of the integration, and it exists only because the hub lives outside your application.

Sync engines — ElectricSQL, PowerSync, Zero — are genuinely excellent, and they solve a much bigger problem than the one you have. They replace your data layer rather than augmenting it: a client-side database, a replication protocol, conflict resolution, a migration story. If you want offline-first local writes, use one. If you just wanted the number on the screen to be current, you've adopted a new architecture to get it.

Hand-rolled SSE is fifteen lines that work perfectly on your laptop and fail in production for reasons nobody on the team remembers a month later:

compression middleware buffers the stream, so nothing arrives until the connection ends
a proxy reaps the connection as idle, and it silently stops delivering
subscribers leak on disconnect, one per tab that ever connected
updates go missing across reconnects, with nothing reporting it

That last one is the reason this post exists.

The failure mode nobody alerts on

A client showing stale data forever is worse than one that polls, because nothing fails. No error is logged. No retry fires. No alert goes off. The page just quietly lies, and the first you hear about it is a support ticket saying the numbers look wrong.

Every other failure in your stack announces itself. This one doesn't. And once you start looking for it, you find it's the default behaviour of almost every naive push implementation: the socket drops, it reconnects, it resumes from somewhere, and nobody checks whether "somewhere" was far enough back.

That gap — between what the server accepted and what the client actually received — is the thing worth engineering around.

Making the gap loud

I've been building aghoz (AH-gohz, from the Filipino agos, "flow") around exactly that idea. It's a small, dependency-free event-stream library that mounts into the app you already have as a route.

Two things follow from mounting in-process.

First, authorization is inherited rather than invented. By the time the handler runs, your session middleware has already established who the user is. So the answer to "may this user read this topic?" is a function call against a request you already parsed:

app.use(session())        // already there
app.use(loadUser)         // already there — sets req.user

app.get('/events', hub.handler({
  authorize: (req, topic) => topic.startsWith(`org/${req.user.orgId}/`),
}))

That one line replaces the entire token subsystem a standalone hub requires. No token exchange, no CORS when the UI and API share an origin, no second service.

Second, an interrupted stream can fail loudly. Two loss conditions are detected and reported through a single callback:

history-truncated — the client reconnected with a cursor older than retained history
slow-consumer — the client couldn't drain its socket and was disconnected rather than left to starve, quietly diverging

<AghozProvider url="/events" onGap={() => queryClient.invalidateQueries()}>

Wire that one prop to a refetch and a client stops trusting a stream the server knows is incomplete. On the client, the migration is about as small as it gets:

- const { data } = useQuery({
-   queryKey: ['revenue'], queryFn: fetchRevenue,
-   refetchInterval: 5000,          // 720 requests per hour, per tab
- })
+ const data = useTopic(`org/${orgId}/revenue`, initial)

Already on TanStack Query? Keep it. Delete the interval and let the stream invalidate:

useTopicInvalidation(`org/${orgId}/orders`, ['orders'])

Two bugs that prove the point

Here's the part I actually want to share, because it's the most useful thing I learned: I shipped this exact bug, twice, in the library whose entire purpose is to prevent it.

Bug one: the empty ring

Truncation was computed the obvious way — truncated = cursor < oldest_retained_event. That's wrong in both directions.

The false positive: 0-0 is the cursor handed out before anything is published, and it sorts below every real id. So on a freshly booted hub, the very first connect replayed everything correctly and reported a gap that couldn't possibly have happened. Every first page load after a deploy refetched. A signal that fires when nothing is wrong is a signal people learn to ignore.

The false negative was worse. An event larger than the entire history budget gets evicted by the push that stored it, leaving the ring empty. With no oldest retained entry, there was nothing to compare against — so the guard short-circuited and a real loss was reported as "nothing missed." Silent staleness, reachable from one oversized publish.

The fix is to track the highest id ever evicted instead:

truncated = last_trimmed !== null && cursor < last_trimmed

Over-reporting is a false alarm. Under-reporting is data loss with no symptom. Those are not equally bad, and the rule should be shaped by which one you'd rather have.

Bug two: the restart

Then, while building persistent history as a performance item, I probed the behaviour it was meant to improve:

life 1: publish …872-0, publish …873-0, process dies
life 2: client reconnects with last-event-id: …872-0
        →  last-event-id-checkpoint: …872-0

An echo. The hub told a resuming client it had missed nothing, while the event published just before shutdown was gone for good. On every restart of every deployment. Since v0.1.

The cause: the previous rule asks "did I drop something you hadn't seen?" — and a restarted hub has dropped nothing, because it remembers nothing. An empty ring and a fresh install are indistinguishable from the inside.

A cursor is also unvouchable from the other end — newer than every id the hub has ever issued:

truncated = evicted || cursor > hub.cursor()

Two lines. A hub that has never issued an id that high cannot know what came after it.

One existing test had asserted the opposite — "an empty hub cannot report truncated, there is nothing to have lost." That intuition is wrong, and it's exactly what hid the bug: an empty hub having nothing doesn't mean the client lost nothing. It means the hub cannot tell. And "cannot tell" must resolve to "refetch," never to "you're fine."

Both bugs existed identically in two independent implementations. That's what convinced me the rules needed to live in one place.

Why Rust — and not for the reason you'd guess

Not for speed. I measured it: a Rust implementation of the hot path, compiled to wasm and called from Node, was slower than plain JavaScript at realistic payload sizes. The Rust logic is genuinely 2.2x faster, but marshalling strings across the boundary gives all of it back and then some — 0.65x at 2 KB payloads. The measurement overturned the plan.

The real reason is one implementation of the rules that must never differ: id assignment (including when the clock moves backwards), topic validation, frame encoding, and the atomicity that makes the checkpoint honest.

This isn't hypothetical. The very first run of the conformance corpus caught a real divergence: the JavaScript hub measured topic length in UTF-16 code units while Rust measured UTF-8 bytes. An 86-character Japanese topic is 258 bytes — rejected by one, accepted by the other, on the exact field whose validation exists to prevent forged frames. Every language has its own wrong answer for "length."

So the protocol is pinned by two language-neutral corpora: 97 vectors for the protocol core and 42 scenarios for the HTTP layer over a real socket. The truncation bugs above each became corpus vectors, verified to fail against the old code first — because fixing it in two places without a vector just leaves the next implementation free to reintroduce it.

The honest costs: a C ABI can't be written without unsafe, so there are 33 unsafe sites in one auditable file, verified in CI by Miri. The protocol logic itself carries #![forbid(unsafe_code)].

What it deliberately doesn't do

Scope is a feature, so the exclusions come before the install line:

It will not work on serverless. Vercel, Lambda, Cloudflare Workers can't hold a long-lived connection. No workaround, none planned.
It is not a sync engine. No offline support, no local writes, no CRDTs, no client-side database. Writes go through the API you already have; the stream is one-way, permanently.
It is not bidirectional. If you need that, use Socket.IO.
Multiple processes need a backplane. @aghoz/redis adds Redis Streams; without it there are zero dependencies at all.

If you need offline-first local writes, use a real sync engine — you'll be happier than with a bad imitation. aghoz is for the case where the server already knows something and the browser should stop asking.

Try it

v0.4.2 is on npm. Node 22+, Express / Fastify / NestJS on the server, React / Vue / Svelte in the browser.

pnpm add @aghoz/server @aghoz/client @aghoz/react

It's early — the API may still change and there's no deprecation policy yet, which is stated at the top of the README rather than discovered later. The protocol is written down, every significant decision is recorded with its evidence (including the three that got reversed), and the example app runs end to end in CI.

Repo: github.com/thinkgrid-labs/aghoz · MIT OR Apache-2.0

If you've hit the silent-staleness failure in your own stack, I'd genuinely like to hear how you found it. In my experience it's never an alert. It's always a support ticket.

Your Coding Agent Can Read the Code—but Can It See the App Fail?

Dencio — Mon, 17 Aug 2026 14:52:44 +0000

TailFlow gives coding agents compact, queryable evidence from the applications
they are changing—without sending local logs to a hosted platform.

Coding agents are increasingly capable of navigating repositories, editing
multiple files, running tests, and explaining unfamiliar systems.

But there is still a gap in the typical agent workflow:

The agent can read the code, but it often cannot see what happens after the
application starts.

A build may pass while the development server fails during startup. A frontend
may compile but crash during hot reload. A background worker may begin retrying
indefinitely. A Docker container may restart with a configuration error.

If the agent cannot observe that output, the workflow usually becomes:

agent edits code
→ checks pass
→ application fails at runtime
→ developer notices the terminal error
→ developer copies the error back to the agent
→ agent tries again

That manual handoff is the problem
TailFlow is designed to solve.

Runtime verification for coding agents

TailFlow is an open-source, local runtime-verification layer for coding agents.

It collects output from:

Development processes
Local Docker containers
Log files
Piped standard input

TailFlow then exposes the same bounded runtime view through:

MCP tools for coding agents
A shell CLI for scripts and terminal-based agents
An interactive terminal UI
A local web dashboard
An HTTP API and Server-Sent Events stream

The goal is not simply to display logs. The goal is to let an agent answer
concrete questions:

Did the expected services actually start?
Did my edit trigger a successful rebuild?
What failed after this change?
Is this a new failure or an old one?
Is the service healthy, or did it never start?
Is this one error repeated hundreds of times?

The resulting loop looks like this:

capture the stack
→ establish a baseline
→ make the change
→ wait for the runtime outcome
→ inspect failures
→ verify the fix

Why tests are not enough

Tests remain essential, but they prove only what they exercise.

A passing test suite does not necessarily prove that:

Environment variables are available
Ports can be bound
Containers can communicate
A development server completed startup
Hot reload succeeded
A background job finished
A real request followed the expected path

Runtime output contains evidence that static analysis and isolated tests cannot
provide. TailFlow makes that evidence accessible to the agent without requiring
the developer to continually watch several terminal tabs.

Getting started in about five minutes

Install TailFlow through npm:

npm install -g tailflow

This installs four commands:

Command	Purpose
`tailflow`	Interactive TUI and project initializer
`tailflow-daemon`	Runtime collector and local API
`tailflow-mcp`	MCP bridge for coding agents
`tailflow-logs`	Shell client for queries and automation

From the root of a project, run:

tailflow init

TailFlow detects common runtime sources, including:

dev, serve, and start scripts in package.json
pnpm, Yarn, Bun, and npm project metadata
Docker Compose files
Common local log directories

It then proposes a configuration:

TailFlow v0.3.2

TailFlow found:

  1. process web: pnpm run dev [recommended]
  2. Docker containers (compose.yml) [recommended]
  3. file worker: logs/worker.log [recommended]

Select sources:

After selection, TailFlow writes a tailflow.toml file. Existing configurations
are never replaced unless --force is explicitly provided.

For noninteractive environments:

tailflow init --yes

You can also specify sources directly:

tailflow init \
  --docker \
  --process 'api=go run ./cmd/api' \
  --file logs/worker.log

Start the collector:

tailflow-daemon

The local dashboard becomes available at
http://127.0.0.1:7878.

Verify the connection from another terminal:

tailflow-logs status
tailflow-logs sources

Connecting a coding agent

For Claude Code:

claude mcp add tailflow -- tailflow-mcp

For another MCP-compatible client:

{
  "mcpServers": {
    "tailflow": {
      "command": "tailflow-mcp"
    }
  }
}

The MCP server gives the agent four focused tools.

`list_log_sources`

Shows which sources are running, exited, failed, or merely observed.

This distinction matters. An empty error list does not prove that a service is
healthy—it may never have started.

`get_recent_errors`

Returns distinct recent failures with occurrence counts and related stack
context.

Instead of filling the agent's context window with the same crash 400 times,
TailFlow can condense it into one failure group:

x400 connection refused: postgres:5432
     at Pool.connect (...)

`search_logs`

Returns exact records with source, severity, time, regular-expression, and
cursor filters. This is useful when exact values or event ordering matter more
than deduplication.

`wait_for_logs`

Waits inside the daemon until a runtime event appears. An agent can wait for:

compiled successfully
server listening
migration complete
request finished
error|failed|panic

This replaces arbitrary sleep-and-poll loops with event-driven verification.

Separating new failures from old failures

One of TailFlow's most important features is its cursor model.

Every captured record receives a monotonically increasing sequence number. The
agent can save the current cursor before making a change and request only
records that appeared afterward.

baseline cursor: 241
        │
        ├── edit application code
        ├── hot reload begins
        └── wait after cursor 241
              ├── compilation succeeded
              └── server ready

This changes the question from:

Are there errors in the logs?

to:

What happened after this specific edit?

TailFlow also reports when the requested cursor has fallen outside its bounded
buffer. That prevents an agent from presenting incomplete evidence as proof
that nothing failed.

One runtime model for developers and agents

TailFlow deliberately gives humans and agents access to the same underlying
data.

Developers can use the terminal UI:

tailflow

Or inspect Docker directly:

tailflow --docker

Shell-based agents and scripts can query the daemon:

tailflow-logs errors --since 5m
tailflow-logs search 'timeout' --source api
tailflow-logs wait --grep 'compiled successfully|Failed to compile'

The web dashboard provides live following, severity filters, source counts, and
regular-expression search.

This shared model makes agent behavior easier to audit: the developer can
inspect the same runtime evidence the agent used to reach its conclusion.

TailFlow is intentionally local

TailFlow is not trying to replace production observability platforms.

It does not provide:

Hosted log storage
Distributed tracing
Metrics or profiling
Production alerting
Multi-tenant access control
Autonomous service remediation

Instead, it focuses on one job:

Give a coding agent timely, compact evidence from the local software it is
changing.

The daemon binds to loopback, stores a bounded in-memory buffer, and does not
require an account or hosted service.

That makes it useful during development, but it also creates important
limitations:

History disappears when the daemon restarts
High-volume stacks can evict older records
Severity detection and error grouping are heuristic
Docker discovery currently follows all local containers
Logs may contain secrets, and TailFlow does not redact them
The local API should not be exposed directly to a network

These boundaries are documented rather than hidden behind a generic “healthy”
result.

What arrived in TailFlow 0.3.2

Version 0.3.2 focuses on reducing setup friction and making the project easier
to understand and operate.

The release includes:

Guided project initialization with tailflow init
Automatic discovery of development scripts, Compose files, and log files
Package-manager-aware generated commands
Safe interactive and noninteractive configuration
Explicit process, file, and Docker source flags
Version banners across the TUI, dashboard, initializer, daemon, and MCP startup
Reworked documentation organized around the runtime-verification problem
Clearer limitations, architecture guidance, feature framing, and roadmap

The broader direction is to make runtime verification a normal step in an agent
coding loop—not a manual debugging step performed only after the agent declares
success.

What comes next

Planned directions include:

Letting the MCP bridge optionally start a local daemon
Serving MCP directly from the daemon over streamable HTTP
Comparing failure groups before and after an edit
Better startup and readiness signals
Compose-aware container selection
Optional bounded local persistence
Correlation across services using request or job identifiers

TailFlow will remain local-first, bounded for agent context, and explicit about
incomplete evidence.

Try TailFlow

TailFlow is open source and licensed under MIT.

npm install -g tailflow
cd your-project
tailflow init
tailflow-daemon

Then connect your coding agent or explore the local dashboard at
http://127.0.0.1:7878.

Project links:

If your coding agent has ever produced a change that looked correct while the
application was visibly failing in another terminal, TailFlow is built for that
missing part of the loop.

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/checkgate-dev/checkgate
Docs: https://checkgate-dev.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/recached-dev/recached:latest
npm install recached-edge

Docs: recached.dev · Source: github.com/recached-dev/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: