DEV Community: Dominic Rockson

The single-process backend: how Yatta JS collapses ten engines into one Bun process

Dominic Rockson — Tue, 20 Oct 2026 16:26:15 +0000

I launched Yatta JS 1.0 a few days ago. That post was the what. This one is the how.

Most backends are a pile of services glued together. Database here, auth service there, queue, cache, mail provider, realtime layer, monitoring. Each one is a network hop, a config, a bill, a 2am failure.

Yatta JS takes the opposite bet: the whole backend is one Bun process. Ten engines share it behind a single yatta/api entry point.

What ten engines means in practice: a type-safe SQLite ORM, auth with passkeys and TOTP two factor on Argon2id hashes and AES-256-GCM sessions, durable job queues with cron and a dead letter queue, L1 plus SQLite L2 cache with stale-while-revalidate, local and S3-compatible storage, transactional mail, unified SSE and WebSocket realtime, SLO observability, and an OpenTelemetry bridge.

One process does not mean one thread doing everything. The worker runtime sizes its CPU and IO pools from the host core count instead of spawning a worker per core. It runs sane on a two-core VPS and a 64-core box with no config changes.

Sharing a process also means sharing memory, and that is where the discipline lives. Streamed request bodies get byte caps so one huge upload cannot eat the process. Token consumption is atomic so two workers never spend the same token. Rate limiting is bounded so forged keys cannot blow up the limiter state. These are the boring details that decide whether single-process is a feature or a footgun.

There is no build step. The TypeScript you write is the TypeScript that runs. One entry point, one process, one runtime to deploy.

The numbers: 889 tests passing. Benchmarks run in CI on every push, and the current numbers are public. On my machine: Yatta JS 12.4k req/s, Hono 13.7k, Elysia 15.9k. On CI runners: Yatta JS 33.6k, Hono 38.6k, Elysia 50k. Slower than the pure routers, on purpose. Every request here passes through a runtime doing real work.

MIT licensed, free forever. Built solo in Liberia.

Docs: https://yatta.js.org
Code: https://github.com/psrockstar098/yatta.js
Install: npm i yatta.js

Yatta JS 1.0 is now live on npm

Dominic Rockson — Sat, 17 Oct 2026 14:30:38 +0000

Yatta JS is a backend-as-a-server for Bun: one runtime with your database, auth, mail, storage, realtime, jobs and observability baked in. No build step — TypeScript runs directly. Open source under MIT, built solo in Liberia. Yatta JS 1.0 is now live on npm — install it with npm i yatta.js: https://www.npmjs.com/package/yatta.js. Docs: https://yatta.js.org — Code: https://github.com/psrockstar098/yatta.js

Yatta JS launches Sunday, October 4

Dominic Rockson — Thu, 01 Oct 2026 18:56:36 +0000

Quick heads up for the weekend. I am releasing Yatta JS on Sunday, October 4.

It is a backend runtime for Bun that embeds the whole stack in your app process: relational DB, passkeys and MFA auth, storage, realtime websockets, durable job queues, transactional mail, plus observability. Boots in under 10ms. No Docker, no brokers.

APIs read like plain English and you get full type safety with zero codegen.

Full launch post drops Sunday.

How rockzy-link's prefetching actually works under the hood

Dominic Rockson — Thu, 01 Oct 2026 11:30:00 +0000

My first post was the announcement. This one is for the curious: how does rockzy-link actually make navigation feel instant? Let's go under the hood.

There are two paths, not one

Most navigation code thinks in one path: click, then fetch, then render. rockzy-link splits it in two:

Prefetch path — something signals intent (hover, focus, a link entering the viewport, browser idle time, or pointerdown). The scheduler starts loading what the route will need.
Navigation path — the actual click. By then the data and route chunks are usually already warm, so the navigation just runs its checks, guards, and router delegation, then renders.

The insight is boring but true: the fastest request is the one that finished before you asked for it.

Intent detection: how it knows you might click

The prefetch prop on <Link> accepts modes:

hover (the default) — best for high-confidence intent: menus, sidebars, expensive pages
viewport — starts prefetching when the link scrolls into view
idle — uses browser idle time, so it never competes with real work
none / false — off

And there's one more trick: pointerdown. When you press the mouse button, the click hasn't happened yet. That gap between press and release is a few dozen to a few hundred milliseconds of free time — rockzy-link fires a high-priority prefetch there too.

<Link to="/dashboard" prefetch="hover">
  Dashboard
</Link>

<Link to="/reports" prefetch="viewport">
  Reports
</Link>

The prefetch scheduler

All of those signals funnel into a smart prefetch scheduler (rockzy-link/prefetch). It doesn't just fire requests blindly:

It dedupes prefetch requests across links and tabs, so ten links to the same route don't trigger ten fetches.
It stays within the browser's connection budget — only a few requests can be in flight at once, and prefetching must never starve the real navigation or the user's current page.

This is the part people miss. Prefetching isn't hard. Polite prefetching is hard.

What actually gets prefetched and cached

Prefetching a route means warming its route data: the JSON/data the page needs, or the HTML/RSC payload depending on the app. rockzy-link stores this in a smart cache with:

TTL — fresh data for a window you control
stale-while-revalidate — serve instantly, refresh in the background
tags — group cache entries and invalidate a whole group at once
mutation invalidation — when you mutate data, invalidate the tags it affects so you never render stale UI

routeCache.set(key, response, {
  ttlMs: 60_000,                // fresh for 1 minute
  staleWhileRevalidateMs: 5 * 60_000, // serve stale for 5 more, revalidate behind
  tags: ['products', 'home'],
});

// later, after a mutation:
routeCache.invalidateTag('products');

The cache also keeps itself bounded (max 500 entries) so a long-lived tab doesn't eat memory.

What happens on click

When the click finally lands, rockzy-link runs the navigation path:

Safety checks and guards — beforeNavigate hooks can cancel
Router delegation — works with React Router, TanStack Router, or the built-in one
Scroll and focus handling — smooth scroll, hash support, focus management for accessibility
Transitions — View Transitions API support, startTransition where it helps
Offline — if the network is down, it serves the cached route instead of a blank page, and queues mutations for later

Then onSuccess fires. If everything was prefetched, steps 1-4 are the only real cost — and navigation feels instant because the data fetch, the slow part, already happened.

The fastest possible path

If you just want raw speed with no router ceremony:

import { runtime } from 'rockzy-link';

await runtime.navigate("/dashboard", {
  router,
  scroll: false,
  announce: false,
  focus: false,
});

Why this matters more than bundle size

For the record: the prefetch scheduler is ~4.24 KB brotli, and core + link is ~2.70 KB. Small. But size isn't the point. Perceived performance is about when work happens, not how much work there is. Move the fetch earlier — to the moment of intent instead of the moment of click — and the same app feels like a different app.

Try it out — it's live on Product Hunt today:

Product Hunt: https://www.producthunt.com/products/rockzy-link?launch=rockzy-link
GitHub: https://github.com/psrockstar098/rockzy-link
npm: https://www.npmjs.com/package/rockzy-link

npm install rockzy-link

I built a React Link component that prefetches before you click

Dominic Rockson — Wed, 30 Sep 2026 00:48:39 +0000

Your app's navigation is only as fast as your Link component. The default one just... navigates. I wanted more, so I built rockzy-link.

What it does

Smart prefetching — analyzes and preloads routes users are likely to visit next, instead of prefetching everything and wasting bandwidth
Route caching — back/forward navigation feels instant
Scroll restoration — users land where they expect
Offline hooks — hooks so your UI degrades gracefully when the network drops
Navigation snapshots — capture and restore navigation state
Accessibility — proper semantics out of the box

Usage

npm i rockzy-link

import { Link } from 'rockzy-link';

// Drop-in replacement — prefetching just works
<Link href="/dashboard" prefetch>Dashboard</Link>

Why I built it

I'm a developer from Liberia working mostly in Zig and JavaScript. I kept hitting the same wall: client-side navigation that felt sluggish no matter how optimized the pages were. The bottleneck was the Link itself. So I fixed it at the source.

It's MIT licensed and I'd genuinely love feedback — try it, break it, tell me what's missing.

npm: https://www.npmjs.com/package/rockzy-link
GitHub: https://github.com/psrockstar098/rockzy-link