DEV Community: Dominic Rockson

Your first transactional email shouldn't need a new account

Dominic Rockson — Sun, 08 Nov 2026 11:53:20 +0000

Every side project eventually needs to send an email: a welcome message, a password reset, a receipt. And that's usually the moment the project quietly grows a second project — a mail-service account, API keys, a template system, a test setup, and the question of what happens when the provider is down.

Yatta JS keeps email inside the backend. It's a backend-as-a-server for Bun: one process with your database, auth, mail, storage, realtime, jobs and observability baked in. The mail engine is already there — createMailer from yatta.js/mail — and it starts in terminal mode, so in development your emails print to the console instead of going anywhere. Nothing to sign up for to write your first welcome email.

When you're ready for real delivery, you change one line: mode becomes smtp in production and you pick a provider preset — Resend, Postmark, SendGrid, SES, Gmail, Mailgun, Brevo — which fills in host, port and TLS for you. The only things you add are credentials and a From address on a domain you've verified. That's the whole integration.

import { createMailer } from "yatta.js/mail";

export const mailer = createMailer({
  defaultFrom: "Yatta App <hello@yourdomain.com>",
  mode: process.env.NODE_ENV === "production" ? "smtp" : "terminal",
  provider: "resend",
});

Templates stay typed: you register a template once with its data shape, and sending it is one call.

await mailer.send({
  to: "user@example.com",
  subject: "Welcome to Yatta!",
  template: "welcome",
  data: { name: "Alice", verifyUrl: "https://app.dev/verify?token=abc" },
});

Markdown in, HTML plus an automatic plain-text version out. There's a preview call that renders the email without sending anything, and a memory mode for tests where you can assert on what was "sent" without touching the network.

The part I like most is the boring safety that comes free: header values are stripped of CR and LF so a subject can't inject extra headers, template values are escaped by default, there's RFC 8058 one-click unsubscribe, idempotency keys, retries for transient failures, and rate limiting you configure in the same object. And the docs' own advice is to send from a job, so a mail failure can't fail a user request — the same job queue that's already in the process.

None of this removes the real work of email — you still have to verify your domain and publish SPF, DKIM and DMARC, or providers will drop your mail. What a bundled backend removes is the week spent assembling a mail stack before your app has sent its first real email.

If your side project has been sitting without a welcome email because the mail setup looked like a whole project, that's the test. Start from a backend where email is already in it, and see how much sooner the first real email goes out.

Yatta JS is open source under MIT, on npm as yatta.js (1.0.5). Docs: https://yatta.js.org — Code: https://github.com/psrockstar098/yatta.js

What's the email your project keeps postponing — welcome, password reset, or receipts?

Auth shouldn't be a second project: passkeys, MFA and sessions in one Yatta JS process

Dominic Rockson — Wed, 04 Nov 2026 11:51:29 +0000

Most side projects don't die on the main feature. They die on the second project hiding inside the first one: auth.

You start out building the thing you actually care about, and then a week disappears into sessions, password resets, login pages, and the question of where tokens live. Add passkeys or MFA and that's another library, another set of docs, another thing to keep in sync with the rest of your backend.

Yatta JS takes a different shape. It's a backend-as-a-server for Bun: one process with your database, auth, mail, storage, realtime, jobs and observability baked in. Auth isn't a service you bolt on — it sits in the same process as the data it protects, next to the same database and the same job queue.

That changes the order of work. Instead of wiring up an auth provider, then a database, then a session store, and then debugging how the three talk to each other, you start with a backend that already has auth in it — including passkeys and MFA — and you go straight to building the feature your users will actually see.

The practical payoff is smaller, not grander. Fewer moving parts means fewer places for a login flow to break at 2am. One process means one log stream when something does go wrong. And when you're ready to ship, the same CLI that checks the rest of the backend — doctor, migrate, backup — covers the whole thing, auth included.

None of this replaces good auth judgment. You still have to decide who can do what in your app, and you still have to think about recovery when someone loses a device. What a bundled backend removes is the plumbing tax: the weeks spent assembling an auth stack before you've shipped anything worth protecting.

If you're building a solo project and auth is the part you've been putting off, that's the test. Try starting from a backend where auth is already there, and see how much sooner you get to the part you actually wanted to build.

Yatta JS is open source under MIT, on npm as yatta.js. Docs: https://yatta.js.org — Code: https://github.com/psrockstar098/yatta.js

What's the auth feature you keep postponing — passkeys, MFA, or just getting sessions right?

Your prototype doesn't need six services — it needs one process

Dominic Rockson — Sun, 01 Nov 2026 11:51:35 +0000

Most of my prototypes never died because the idea was bad. They died before they got a fair test, buried under the setup.

A database here. Auth somewhere else. A queue service, a mail provider, a realtime layer, a place to watch logs. Each one is small on its own. Together, before a single user has touched the thing, I am maintaining six services for an idea I have not validated yet.

That is a strange trade for a prototype. The whole point of a prototype is to learn fast. Every service I add before launch is a decision I have to maintain, a credential to rotate, and a dashboard to check — all for an app that might get ten users this week.

Yatta JS is the backend I reach for now when the idea is small but the deadline is real. It is a backend-as-a-server for Bun: one process with your database, auth, mail, storage, realtime, jobs, and observability baked in. No build step — TypeScript runs directly. The prototype and its backend are the same thing, not a diagram of services I have to keep in sync.

What changes in practice is the order of work. Instead of spending the first evening wiring services together, I spend it on the actual feature: the data model, the realtime update, the job that runs after signup. If the prototype works, it is already running on a real backend, not a mock I have to rebuild later. If it does not, I have lost an evening, not a week of infrastructure.

There is a real trade-off, and I will not hide it. One process is not the right shape for every workload, and a prototype that finds real traction will eventually outgrow it. But that is a good problem — it means the idea survived contact with users. Most prototypes never get there, and the ones that die from setup overhead never even get the chance.

So my rule now is simple: the prototype gets one process. If it earns more, it can earn more infrastructure later.

Yatta JS is open source under MIT, on npm as yatta.js. Docs: https://yatta.js.org — Code: https://github.com/psrockstar098/yatta.js

What kills your prototypes: the setup, or something else?

Your side project doesn't need a database server

Dominic Rockson — Wed, 28 Oct 2026 11:51:45 +0000

Every side project I start used to begin the same way: pick a framework, then pick a database, then figure out where that database lives. A hosted Postgres for the real thing, something else locally, connection strings in three places, and a migration story to sort out before I'd written a single feature. The database decision alone could eat the first evening.

Yatta JS removes that first evening. It's a backend-as-a-server for Bun, and the database is already inside it — a built-in database with a type-safe ORM, sitting in the same process as the rest of the backend. There is no database server to provision, no connection string to babysit, and no separate service to keep awake for a project with twelve users.

That changes how a first feature feels. The data your API serves lives next to the code that serves it. You define the shape, you read and write it from the same runtime, and the thing you deploy is one process, not a diagram of services. Auth, mail, storage, realtime, jobs, and observability live in that same process too, so the usual "I'll add that later" pieces are already there when later arrives.

The honest boundary: a built-in database is the right call at solo and small-team scale. It is not a claim that one process replaces a dedicated database cluster forever — if a project ever outgrows it, that means it found users, which is a good problem. But most side projects never die from scale. They die from setup, and a database server is often the first piece of setup that kills the momentum.

So the rule I use now: if the project is small, keep the database in the app. Yatta JS is on npm as yatta.js — install it with npm i yatta.js — and the docs are at https://yatta.js.org. Code: https://github.com/psrockstar098/yatta.js

What killed your last side project's momentum — the database setup, auth, or something else?

Before you ship your side project, run three commands: Yatta JS's doctor, migrate, and backup

Dominic Rockson — Sat, 24 Oct 2026 11:51:34 +0000

Side projects rarely die because the idea was bad. They die in the gap between "it works on my machine" and "it survives real users" — the database migration nobody ran, the backup nobody took, the misconfiguration nobody noticed until launch day.

Yatta JS is a backend-as-a-server for Bun: database, auth, mail, storage, realtime, jobs, and observability embedded in your application process instead of provisioned as separate services. It is live as yatta.js@1.0.0 on npm — install it with npm i yatta.js — and the docs are at https://yatta.js.org. What I want to talk about today is not the architecture, though. It is the three boring commands that sit between a demo and a shipped thing.

Doctor first: check the patient before the launch

Every framework has a setup guide. Few of them will look at your actual project and tell you what is off. Yatta's doctor command does that job: it checks your project setup and flags problems before they become launch-day surprises.

My rule now is simple: doctor runs before every deploy, not after something breaks. It is the cheapest form of confidence a solo builder can buy, and it costs nothing because the check is local to your own project. If you take one habit from this post, take this one — verify the setup, don't assume it.

Migrations as a normal part of the workflow, not a scary event

A side project that never changes its data model is a side project that never ships a second feature. Yatta's CLI treats migrations as ordinary work: make a migration, check migration status, run the migration. That rhythm matters more than any single command, because it turns schema changes from a dreaded manual step into a repeatable one you do without thinking twice.

The practical payoff is unglamorous and real: your local database, your staging data, and your production data move forward in the same steps, in the same order. When you are the only person on the project, that repeatability is your whole ops team.

Backup before you need it, not after you lose something

Yatta's CLI includes database backup and restore commands, and the honest truth is that most solo projects never test a restore until the day they need one. Build the habit the other way round: take a backup before a risky migration, and know that restore is a command you have already practised, not a README you are reading in a panic.

That is the whole pre-ship checklist, and it fits in a short paragraph: run doctor, keep migrations routine, back up before risky changes. None of it is exciting. All of it is what keeps a one-person project alive past week two.

None of this replaces good judgement — a backup you never tested is a hope, not a plan, and a migration you never reviewed is still your responsibility. But having doctor, migrate, and backup as first-class commands in the same runtime that already holds your database, realtime, and jobs means the unglamorous work stops being a separate project. It is just part of shipping.

If you are building on Bun and you are tired of assembling a backend from six services before you write a single feature, Yatta JS is worth a look: https://yatta.js.org — npm: https://www.npmjs.com/package/yatta.js — code: https://github.com/psrockstar098/yatta.js

What is the one pre-launch check you always skip and always regret? I would genuinely like to steal better habits from the comments.

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