DEV Community: Dencio

Introducing Recached: Cache Locally, Sync Everywhere

Dencio — Sun, 25 Oct 2026 12:06:08 +0000

Imagine a dashboard showing inventory levels. Your backend has the latest value, but the browser has an older copy. Another tab needs the same update. A mobile app goes offline and reconnects later.

A seemingly simple cache now involves several moving parts: server-side caching, API requests, client-side state, invalidation, WebSocket events, and reconnection logic.

What if the cache could live inside the application—and synchronize with the server?

That's the idea behind Recached, an open-source, local-first cache and real-time sync engine powered by Rust.

Cache locally. Sync everywhere.

Recached is designed to keep shared cache data close to where it's used: inside a browser, a native mobile app, or a backend service. Applications can read cached values from local memory while changes flow between the server and connected clients.

The problem: caching doesn't end at the backend

A traditional cache such as Redis is great for keeping frequently accessed data close to your server. But if that data also needs to appear in an interface, you often end up building another system around it:

Your backend writes a value to the cache.
Your frontend polls an endpoint or receives a custom WebSocket event.
Client-side code updates another cache or state store.
When a device reconnects, you decide what it missed and how to recover.

None of these steps is inherently wrong. But they're recurring infrastructure tasks, especially in real-time dashboards, shared application state, and offline-capable applications.

Recached combines the cache and its synchronization path. The backend can continue using a familiar Redis client, while supported clients maintain a local view of the keys they watch.

How Recached works

At its core, Recached uses a shared Rust cache engine across its server and client runtimes.

                Your backend / API
                       |
              Redis client (RESP)
                       |
                       v
               +----------------+
               | Recached       |
               | server         |
               +----------------+
                       |
                 WebSocket sync
                       |
           +-----------+-----------+
           |           |           |
           v           v           v
       Browser      Mobile      Rust service
       (WASM)       (native)     (embedded)
           |           |           |
       Local cache Local cache Local cache
           |           |           |
       Local reads  Local reads  Local reads

The two important paths are different:

Backend writes: Existing Redis clients communicate with the Recached server using its supported RESP command subset.
Client reads: Browsers, mobile apps, and embedded Rust services read from their own local cache. Watched server data arrives through WebSocket synchronization.

A client can subscribe to key patterns to obtain an initial snapshot and later changes. Reconnecting clients can reconcile missed updates. An initial read may still miss until the first snapshot has arrived, so applications should handle loading and synchronization state.

Let's build a tiny live inventory example

Here's a local development setup with a Node.js backend and a browser client.

1. Start the Recached server

Run it with Docker:

docker run -p 6379:6379 -p 6380:6380 ghcr.io/recached-sh/recached:latest

By default, 6379 is the Redis-compatible RESP port and 6380 is the WebSocket sync port.

You can verify the server responds:

redis-cli ping
# PONG

Security note: This is a localhost development example. Do not expose a default server publicly: authentication, TLS, browser-origin restrictions, and key-level sync scopes need to be configured for your deployment.

2. Write a value using a Redis client

Install ioredis in your Node.js project:

npm install ioredis

Then use the familiar Redis API:

import Redis from 'ioredis';

const cache = new Redis('redis://127.0.0.1:6379');

await cache.set('inventory:item:99', '42');

The backend doesn't need a custom Recached driver. It uses the supported commands through a standard Redis client.

3. Read it locally in the browser

Install the browser SDK:

npm install recached-edge@^0.4.0

Recached runs its cache engine in the browser through WebAssembly:

import { createCache } from 'recached-edge';

const cache = await createCache({
  connect: { url: 'ws://127.0.0.1:6380' },
});

// React whenever this local key changes.
const unsubscribe = cache.onKeyChange('inventory:item:99', () => {
  console.log('Inventory:', cache.get('inventory:item:99'));
});

// Request an initial snapshot and subsequent updates.
cache.liveQuery('inventory:*');

// This is a local-memory read; it can be null before hydration.
console.log(cache.get('inventory:item:99'));

// Call unsubscribe() when the listener is no longer needed.

Now change the value from your backend:

await cache.set('inventory:item:99', '41');

The subscribed browser receives the change, updates its local cache, and invokes the change listener. The UI doesn't have to poll an API endpoint to discover the new value.

The interesting part isn't merely that Recached uses WebSockets. It's that the value you read is already held inside the application.

It also works without a server

The browser package can be used as a standalone local cache. Simply omit the connect option:

import { createCache } from 'recached-edge';

const cache = await createCache({
  persistence: true,
  broadcastChannel: 'my-app',
});

cache.setJSON('settings', { theme: 'dark' }, 3600);

const settings = cache.getJSON('settings');

In this mode, you can use local cache operations, TTLs, JSON values, optional IndexedDB persistence, and cross-tab mutation sharing through BroadcastChannel—without running a Recached server.

Browser persistence has limits: it records local writes, not every server-pushed value. It's important to understand what will be available after a page refresh, especially in applications that connect to a server. The persistence documentation explains the contract.

One engine, multiple runtimes

Recached's shared Rust foundation extends beyond the browser:

Runtime	Integration	What it offers
Browser	`recached-edge` (WASM)	Local cache, WebSocket sync, optional IndexedDB persistence
React / Vue	`@recached/react`, `@recached/vue`	Reactive adapters for the browser cache
Android	Kotlin SDK	Native Rust core, SQLite persistence, Kotlin `Flow` observers
iOS / macOS	Swift SDK	Native Rust core, SQLite persistence, Swift async observation
Rust services	`recached-embed`	In-process cache for watched server data

The APIs and durability guarantees aren't identical across platforms. The Android and Apple SDKs are 0.1.0 previews, the browser sync layer is beta, and the embedded Rust client is currently an unpublished Git dependency.

For example, a Rust service can keep frequently read feature flags or configuration values in its own process memory instead of fetching them over the network on every request. A native mobile app can restore cached data from SQLite after restarting offline and reconcile when it reconnects.

Where it fits—and where it doesn't

Recached is useful when you need:

Live dashboards: Counters, status changes, and operational data that should update without polling.
Shared client-visible state: A cache that multiple tabs or devices can observe.
Offline-capable applications: Previously saved reference data and queued cache writes that can reconcile after reconnecting, subject to documented limits.
Local configuration reads: Feature flags and tenant settings used frequently by application services.

But it's important to be specific about what Recached is not.

It's not a replacement for PostgreSQL or MySQL. Your database should remain the source of truth. Publish committed state into Recached as a derived cache; a cache write is not a database transaction.

It's not a drop-in replacement for every Redis workload. Recached supports a subset of Redis commands, but does not implement features such as Lua scripting or Redis Streams. Software that depends on those primitives may not work, even though its Redis client can connect.

It's not a general-purpose CRDT engine. Conflicting writes do not get automatic, application-aware conflict resolution, and queued writes are not a durable business transaction system.

This distinction matters. Recached is designed around local cache reads plus real-time synchronization, not maximum Redis compatibility or database replication.

A critical production consideration: sync scopes

Real-time synchronization also creates an authorization problem. In the default unscoped configuration, server mutations can be pushed to every connected WebSocket client. That's not appropriate for a multi-user application.

Recached provides sync scopes so your backend can mint signed tokens granting read or read/write access to specific key patterns. A user might receive read access to catalog:* and read/write access only to their own cart keys.

Watching a pattern is not the same thing as having permission to see it. Before building a multi-user app, read the sync scopes guide and security documentation.

What stage is the project at?

Recached is open source under the Apache 2.0 license, and it's still evolving.

The cache server is described as a release candidate for cache workloads, while the synchronization layer is beta and the native SDKs are early previews. The project has automated tests and documented performance measurements, but has not completed broad production validation or an independent security audit.

The goal isn't to claim that every application should replace its current cache. It's to explore a different developer experience: write cached data once, keep useful copies near applications, and synchronize changes without rebuilding the same plumbing in every project.

Try Recached

If you're building a real-time web app, an offline-capable mobile experience, or a service that repeatedly reads shared configuration, Recached may be worth experimenting with.

GitHub: github.com/recached-sh/recached
Documentation: recached.dev
Quick start: recached.dev/guide/quick-start
Client support and limitations: recached.dev/guide/client-support

I'd love feedback from developers working on caching, local-first software, WebAssembly, or real-time synchronization. What would you want from a cache that runs inside both your server and your applications?

Meet Kepta: Remember What Happened to the Things You Own

Dencio — Wed, 14 Oct 2026 04:14:17 +0000

You lend someone a drill. A few weeks later, you need it and cannot remember who has it.

You get your bike repaired. Months later, it starts making a noise, and you wonder what the shop replaced last time.

You put your passport somewhere safe. Now you need to remember where “safe” was.

Kepta gives those details a place to live. It is a private Android app for keeping track of the things you own and what happens to them, so you can find the answer when you need it.

Write it down while you remember

Capturing an everyday detail should take a moment. In Kepta, you can start with a sentence:

Changed the chain on the bike yesterday, paid 850 pesos at CycleHouse.

If you have added your bike and CycleHouse, Kepta can connect the sentence to them and suggest the event, date, and amount. You review what it understood, make any corrections, and save.

Tell Kepta that you call your Trek FX 3 “bike,” and you can use that name when writing about it.

The next time you need the repair date or the cost, you have a record to return to.

Keep the history with the thing

A laptop, bicycle, camera, or appliance can accumulate a lot of details over the years. Kepta brings them together on that thing's timeline.

Keep track of:

Repairs and maintenance: what happened, when, who did it, and what you paid.
Loans and returns: who borrowed something and whether it came back.
Storage and moves: where you put something, with a record you can check later.
Purchase and warranty details: the price, serial number, model, and warranty expiry.

You can also attach photos of receipts, serial plates, or damage to a record. When you need to explain a problem to a repair shop, the history and the evidence are together.

Find the answer when it matters

Some details are useful only months after you save them.

Search for a thing or a phrase to find your records. For supported questions about loans and locations, Kepta can give you an answer with the saved memory behind it.

Ask “who has my bike,” and it can show the borrower and the loan record. Look up where something is kept, and you can check the memory that placed it there.

For repairs and maintenance, open the thing's timeline to see what happened last time. You have your own history to work from when deciding what to do next.

Let your records remind you

A warranty date is easy to forget until something breaks. A borrowed item is easy to lose track of until you need it.

Kepta offers reminders based on the details you have already recorded, including approaching warranty expiries and outstanding loans. Accept a reminder, and your phone handles the notification.

Keep your everyday life private

Your records can reveal plenty about your life: what you own, who you know, and where you keep things.

Kepta keeps those records on your phone. It works entirely offline, with no account to create, no analytics, and no advertising. The app distributed on Google Play has no internet permission.

Your saved records and attached photos are encrypted. Unlock with your PIN or optional fingerprint unlock, and Kepta locks again when you leave the app.

You can use it in airplane mode, in a workshop with poor reception, or wherever a detail is worth remembering.

A quick note for developers

Kepta is built with React Native and TypeScript, with TalaDB as its embedded database. Capture uses local parsing rules, and search combines structured records with full-text search. Both run on the phone without sending your text to an AI service. Semantic search is planned for a future version.

Start with one thing

Add something you regularly repair, lend, or misplace. Save its purchase details, record its next service, or note who you lent it to.

Each time something happens, add a sentence. Over time, you build a history you can turn to instead of searching through old messages and photos.

Get Kepta on Google Play

What is the first thing you would keep track of?

Tanod: protecting self-hosted Next.js from SSR overload

Dencio — Thu, 08 Oct 2026 08:03:03 +0000

A cache can absorb a burst of requests for one popular product page. But a crawler visiting thousands of different product pages creates a different problem: every URL may need its own render.

Your application can be busy generating responses that nobody else will reuse. Meanwhile, ordinary visitors are competing for the same rendering capacity.

Tanod is an open-source Rust reverse proxy for controlling origin work in server-side rendering (SSR) and other expensive HTTP applications. It combines concurrency limits, bounded queues, request coalescing, and short-lived caching, with a dedicated integration for self-hosted Next.js.

Its goal is to stop traffic spikes from becoming render spikes.

The problem with counting requests alone

Two HTTP requests can place different demands on your server. One returns a static file. Another renders a page, queries a database, and calls a content management system.

A requests-per-second limit does not express how much of that work may be active at once. Longer responses can leave the origin with more concurrent work even when the arrival rate stays the same.

For an illustrative steady-state workload, 40 requests per second with a 500 ms response time means about 20 requests in flight. If response time grows to 1.5 seconds at the same arrival rate, that becomes about 60. Those numbers describe the relationship, not a benchmark or a recommended server capacity.

Caching and client rate limits still matter. They address different parts of the problem:

Mechanism	What it controls
Client rate limiting	How much traffic a client may send over time
Response caching	How much repeated work can be avoided
Request coalescing	How many identical concurrent requests need separate origin responses
Origin admission control	How much new origin work may run at once

Tanod concentrates on the last three. You still need an appropriate public edge and client rate limiting.

What Tanod does

Tanod runs in front of your application server, also called the origin. Place it behind a content delivery network (CDN), an edge proxy, or a load balancer:

Browser / crawler
      ↓
CDN / Caddy / NGINX / load balancer
      ↓
Tanod
      ↓
Next.js or another HTTP application

The edge handles responsibilities such as certificate management and client rate limits. Tanod handles origin capacity and eligible response reuse.

Tanod is built on Pingora, Cloudflare's Rust proxy framework. Its application-specific layer adds route classification, response-sharing policy, and bounded origin admission.

The name comes from the Tagalog tanod: a barangay watchman who keeps order at the gate.

Reuse first, then spend origin capacity

The ordering matters because a cache hit should not wait for capacity that it does not need.

For governed requests, Tanod follows this sequence:

Match the route and classify the request.
Reuse an eligible cached response or attach to a safely shareable in-flight response.
Acquire the configured route and global capacity permits for remaining origin work.
Wait within a bounded queue if capacity is busy.
Forward admitted work, or reject it when the queue is full or its deadline expires.
Check the origin response before sharing or storing it.

Request coalescing means equivalent concurrent requests can receive one origin response. Microcaching means an eligible response is stored briefly so later requests can reuse it.

Neither helps when every request is a distinct, uncacheable miss. The concurrency ceiling still applies to that work, including private dynamic requests.

You configure the limits and optional route weights. Tanod does not automatically measure the CPU or memory cost of a render, and it cannot infer your origin's safe capacity.

Overload needs a defined response

A queue is useful only when it has an end. Allowing unlimited requests to wait can move the overload from the application into the proxy.

Tanod bounds both queue size and waiting time. When it cannot admit a request, the default response is 503 Service Unavailable with a Retry-After header.

For a browser loading a document, Tanod can return a configurable busy page that refreshes automatically. API clients and Next.js payload requests receive the error status without that HTML page.

The busy page is a retry mechanism, not a reserved place in line. Each refresh is a new request.

Eligible stale content can be served during background revalidation or an upstream failure. It is not currently served as a fallback for overload shedding. That distinction matters when choosing how a public page should behave under load.

Response sharing requires a privacy decision

A popular URL is not necessarily a public response. A product page might include account information, a customer-specific price, or a session cookie.

Tanod checks both request eligibility and response shareability. Its rules include:

Requests with Authorization and unsafe methods bypass sharing
Cookie-bearing requests are private by default
Responses containing Set-Cookie cannot be shared through a route override
Unsupported response Vary headers prevent sharing
Origin private, no-cache, and no-store directives are respected unless a validated public route explicitly overrides them

A public-route override is an application privacy assertion. It requires reviewing what the route returns, including for visitors who send cookies. It does not make a personalized response safe to share.

This is why a first deployment can enable origin protection while leaving caching and coalescing disabled. You can review public routes separately after measuring the origin.

Next.js needs more than a URL-based cache key

With Next.js, the same URL can return an HTML document or a React Server Components (RSC) payload. Prefetch requests introduce additional variants, while Server Actions and draft mode need their own handling.

Tanod's Next.js adapter accounts for those distinctions. Cache keys separate relevant framework variants, and Server Actions and draft-mode content bypass response sharing.

The companion @tanod/next package reads production build manifests to generate route configuration. Dynamic pages and Route Handlers remain private unless you approve them through a checked-in policy. Prerendered routes can receive public policies based on build evidence.

There is also an invalidation boundary to understand: calling Next.js revalidateTag() or revalidatePath() alone does not invalidate a response held by Tanod. The package provides integration for coordinating both caches.

Tanod can proxy other HTTP applications with manual route configuration. Next.js currently has the dedicated build integration; equivalent integrations for other frameworks remain future work.

Try origin protection locally

This walkthrough starts with sharing disabled. It requires Linux x64, a Rust toolchain, and a Next.js application you can build and run locally. Tanod declares Rust 1.88 as its minimum; the repository pins its build toolchain in rust-toolchain.toml.

In a terminal inside your Next.js project, build and start the origin on loopback:

npm run build
npx next start --hostname 127.0.0.1 --port 3000

In a second terminal, clone Tanod and build its binary:

git clone https://github.com/akosidencio/tanod.git
cd tanod
cargo build --release --locked

Generate a local configuration that forwards to your running application:

./target/release/tanod init \
  --config tanod.local.yaml \
  --upstream 127.0.0.1:3000 \
  --listen 127.0.0.1:8080 \
  --concurrency 16

The generated configuration admits up to 16 concurrent origin work units and allows up to 32 queued requests, with a two-second queue deadline. Its private catch-all disables caching and coalescing.

The value 16 is a starting point for experimentation, not a recommendation for your application. Measure representative requests, origin memory use, latency, and queue waits before choosing a deployment limit.

Validate the configuration, then start the proxy:

./target/release/tanod check --config tanod.local.yaml
./target/release/tanod run --config tanod.local.yaml

In another terminal, send a request through Tanod and inspect its separate admin listener:

curl -i http://127.0.0.1:8080/
curl -fsS http://127.0.0.1:9091/health/live
curl -fsS http://127.0.0.1:9091/status

Application traffic enters on port 8080; administrative checks use port 9091. Keep the admin listener private in a public deployment.

For a server installation with systemd and a public domain, follow the standalone guide.

Test the case where caching cannot help

The repository includes a focused admission-control demonstration. From the Tanod directory, run it separately from your application traffic:

./bench/demo.sh 60 1000

The script starts a fixture origin and sends 60 concurrent requests for 60 distinct URLs. Each fixture response simulates one second of work. The benchmark configuration sets the origin ceiling to 10 and disables caching.

It compares direct traffic with traffic through Tanod. The origin reports its own peak concurrency, and the script asserts that the direct run exceeds the configured ceiling while the governed run stays within it.

The fixture sleeps rather than performing a real React render. This checks admission behavior, not Next.js throughput. It also demonstrates the trade-off: serializing work into smaller groups can take longer when the origin could have handled the entire batch.

The repository has separate Next.js HTTP, browser, and replica checks. Those exercise framework behavior, response isolation, invalidation, and deployment boundaries.

What to measure before tuning a limit

The useful question is how your origin behaves as concurrent work grows. Request totals alone cannot answer it.

Tanod exports Prometheus metrics, structured logs, and optional OpenTelemetry data. A Grafana dashboard and alerting rules help inspect:

Origin work in flight compared with the configured ceiling
Queue waiting time and total request duration
Responses shed by Tanod
Origin latency and backend health
Cache reuse and memory occupancy

Raising a concurrency ceiling can reduce queueing or increase overload. Check the origin's behavior before treating either outcome as an improvement.

Current limits and the next steps

The version covered here is 0.3.0, and Tanod remains pre-1.0. Repository tests and bounded staging tests support its mechanisms, but sustained production validation and an independent cache-safety review remain open.

There are deployment boundaries to account for:

Cache and coalescing are local to each process
Several proxies sharing one origin pool need statically partitioned capacity budgets
Purges must reach every instance that can hold a cached response
Exact-path purges do not expand dynamic route patterns
Slow readers can keep origin permits occupied; optional bounded spooling sacrifices progressive rendering to release capacity earlier
Static and long-lived streaming classes do not use render permits; WebSocket upgrades have separate limits

Tanod can also supervise one local application through origin.command, allowing the app and proxy to run within one container or service. That simplifies the process arrangement, but each instance still owns its own cache and capacity boundary.

The roadmap focuses on deployment validation, independent review, overload behavior, and additional integrations. Tanod aims to make origin overload controlled and observable; it does not promise that every application becomes faster or cheaper.

Try Tanod with a workload you understand

If you operate an expensive self-hosted origin, start by measuring concurrent work and response latency. Try Tanod with private defaults, set a capacity budget, and inspect what happens when that budget is reached. Enable response reuse only after reviewing the routes that can safely share it.

The project is available under the Apache 2.0 license:

Feedback on self-hosting workloads, reproducible failures, and cache-safety assumptions can help determine the next priorities. When reporting behavior, include a redacted configuration, the request pattern, and the Tanod version.

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/akosidencio/aghozghoz · 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: