Dulak | Notes

Nginx is dead. Cloudflare killed it

Sun, 09 Aug 2026 00:00:00 GMT

Every deployment guide for a web app has the same section. “Now install Nginx.” Then a config file. Then Certbot. Then a cron job to renew the cert. Then proxy_set_header lines you copy-paste without reading. Then you debug why X-Forwarded-For is wrong and your rate limiter thinks every user is the same IP.

Nginx has been the default reverse proxy for 25 years. It’s good software. But if your domain is on Cloudflare — and in 2026, why wouldn’t it be — you’re installing Nginx to do five jobs that Cloudflare already does, for free, at 300+ edge locations worldwide.

The five jobs Nginx does

When you put Nginx in front of a Node/Bun app, it does these things:

TLS termination — HTTPS cert, renewal, cipher negotiation
Reverse proxy — forward requests to the app port
Gzip compression — shrink responses before they hit the wire
Rate limiting — limit_req_zone, burst queues, 429s
Static file serving — serve assets without hitting the app

That’s the Nginx config you maintain. Let’s go through each one.

Job 1: TLS termination

Nginx + Certbot:

server {
    listen 80;
    server_name your-domain.com;
    location / {
        proxy_pass http://127.0.0.1:4000;
    }
}

sudo certbot --nginx -d your-domain.com
# plus a cron job to renew
# plus cipher suite configuration
# plus HSTS headers

Cloudflare: you click “Proxied” on your DNS record. TLS is terminated at the edge. The cert is issued, renewed, and rotated automatically. You pick “Flexible” or “Full” mode in the dashboard. That’s it. No Certbot, no renewal cron, no cipher negotiation.

Job 2: Reverse proxy

Nginx:

location / {
    proxy_pass http://127.0.0.1:4000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_http_version 1.1;
}

Cloudflare: the edge proxies to your origin. Two options, neither requires a config file:

Proxied DNS — an A record with the orange cloud. Traffic flows through Cloudflare to your server on port 4000. One firewall rule restricts port 4000 to Cloudflare IPs only.
Cloudflare Tunnel — cloudflared connects outbound. No open ports, no firewall rules, no public IP needed. Your server is invisible to the internet.

The proxy_set_header dance? Cloudflare passes Host and X-Forwarded-For through by default. If the Host header gets rewritten, one Origin Rule in the dashboard fixes it — no config file syntax to learn.

Job 3: Gzip compression

Nginx:

gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_min_length 1024;

Cloudflare: compresses responses at the edge with brotli or gzip, automatically, based on the client’s Accept-Encoding. You don’t configure anything. It’s on by default.

But here’s the thing — Dulak also compresses in-process. The compress.ts middleware gzips SSR HTML and asset bundles using node:zlib:

// Only /assets/* (js/css bundles) and SSR HTML are compressed —
// API/JSON responses pass through untouched.
if (!c.req.path.startsWith("/assets/") && !IS_HTML.test(type)) return;

So even without Cloudflare, Dulak handles compression. With Cloudflare, responses are double-optimized: the origin gzips, the edge can re-compress or serve as-is. No Nginx needed for either layer.

Job 4: Rate limiting

Nginx:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location / {
    limit_req zone=api burst=20;
    proxy_pass http://127.0.0.1:4000;
}

Dulak has its own rate limiter — in-memory, zero dependencies, in rate-limit.ts:

function clientKey(request: Request, server: BunServer | null): string {
  const forwarded = request.headers.get("x-forwarded-for");
  if (forwarded) return forwarded.split(",")[0]!.trim();
  const ip = server?.requestIP?.(request)?.address;
  return ip ?? "local";
}

Two layers: a global limiter (DDoS baseline, 200 req/min per IP) and a stricter one on auth endpoints (30 req/min, brute-force protection). Cloudflare sits in front with its own DDoS protection and rate limiting rules — so by the time traffic reaches Dulak, the volumetric attacks are already filtered. The in-app limiter handles the application-layer abuse that Cloudflare can’t see (brute-force login attempts, etc).

Nginx’s limit_req sits awkwardly in the middle — it can’t see application semantics, and it’s redundant with Cloudflare for volumetric protection. Dulak’s limiter sees the actual routes and can differentiate /login from /dashboard. Nginx can’t.

Job 5: Static file serving

Nginx:

location /assets/ {
    alias /var/www/dulak/dist/;
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Dulak serves its own assets. Bun.serve handles static files directly — the asset pipeline in assets.ts builds, fingerprints, and serves bundles with correct cache headers. No alias directive, no root path to keep in sync with your build output.

And Cloudflare caches static assets at the edge automatically. The first request hits your origin; subsequent requests are served from the nearest Cloudflare location. You don’t configure cache rules for fingerprinted assets — the immutable cache header does it for you.

What you actually deploy

Without Nginx, the deployment is:

Internet → Cloudflare edge (TLS, DDoS, cache, brotli) → your-server:4000
                                                            └→ Bun.serve (app + assets + gzip + rate limit)
                                                                 └→ SQLite + uploads

One process. One port. No proxy config file. No cert renewal. No nginx -t && systemctl reload nginx after every config change.

The VPS deployment is a systemd unit:

[Service]
ExecStart=/home/dulak/.bun/bin/bun run src/index.ts
Restart=always

Plus a DNS record with the orange cloud. That’s the entire production setup. No Nginx package, no Nginx user, no Nginx logs to rotate, no Nginx security updates to track.

With Cloudflare Tunnel, it’s even simpler — no open ports, no firewall rules, no public IP. The tunnel connects outbound and Cloudflare routes traffic to it. Your server is a dark node that only talks to Cloudflare.

Fewer layers, fewer milliseconds

Every hop in your stack adds latency. With Nginx in the middle, a request travels:

User → Cloudflare edge → Nginx (on your server) → Bun

That Nginx hop is a proxy_pass to 127.0.0.1:4000 — a TCP connection, header parsing, and a second process wake-up, all on the same machine. It’s not a network round-trip across the country, but it’s not free either: Nginx adds ~0.5-1ms per request on a typical VPS, plus memory for worker processes, plus context switches between Nginx and Bun.

Remove Nginx and the path becomes:

User → Cloudflare edge → Bun

One fewer process. One fewer hop. One fewer allocation path. The request lands in Bun directly, and Bun handles TLS (if Full mode), routing, compression, and the app — all in one process. For a page that makes 5 API calls, that’s 5× the per-request overhead removed. On a budget VPS where CPU is scarce, that’s real.

The deeper point: every layer you add is a layer that can break, misconfigure, or silently rewrite headers. Nginx rewriting Host or mangling X-Forwarded-For is a classic deployment bug. Cloudflare + Bun is two layers that talk directly. Fewer moving parts, fewer midnight debugging sessions.

The cert renewal cron you deleted

Certbot installs a systemd timer that renews certs every 12 hours and reloads Nginx. If renewal fails — Let’s Encrypt rate limit, expired account, DNS change — your site goes dark in 90 days. You won’t notice until it does.

Cloudflare’s edge certs are managed by Cloudflare. You don’t see them, you don’t renew them, you don’t reload anything. If you want an origin cert for Full mode, Cloudflare issues it from their CA for free, with a 15-year expiry. No cron, no timer, no 3am pager alert because Let’s Encrypt had an outage.

When you still need Nginx

Nginx isn’t dead for everyone. It has legitimate use cases:

You’re not on Cloudflare — some teams can’t or won’t use a third-party proxy. Nginx + Certbot is the self-hosted path. Dulak’s reverse proxy guide covers it.
You need complex routing — multiple upstreams, weighted load balancing, path-based routing to different apps. Nginx is a real load balancer; Cloudflare’s free tier isn’t.
You’re serving huge static files directly — if you’re a CDN backend serving terabytes of video, Nginx’s sendfile and aio are tuned for that. Dulak serves fingerprinted JS/CSS bundles, not media.
Regulatory constraints — some jurisdictions require all infrastructure to be self-hosted. Cloudflare’s edge is outside your control.

None of these apply to a typical Dulak deployment: a single-process app on a VPS, domain on Cloudflare, SQLite on disk. For that setup, Nginx is a dependency that duplicates work Cloudflare and Bun already do.

The short version

Nginx terminates TLS, proxies, compresses, rate-limits, and serves static files. Cloudflare does the first four at the edge. Dulak does the last three in-process. There’s nothing left for Nginx to do.

You’re maintaining a config file, a cert renewal cron, and a package to track — for a proxy that proxies to a proxy. Delete the middleman. Point Cloudflare at Bun and go home.

Read the full Cloudflare setup in the reverse proxy guide — Option A1 (Proxied DNS + Origin Rule) is the recommended path.

bcrypt is from 1999. Your passwords deserve better

Sat, 08 Aug 2026 00:00:00 GMT

Every password hashing comparison reaches the same question: “bcrypt works fine, why change?”

It does work fine. Nobody is saying bcrypt is broken. But “not broken” and “the right choice for a new project in 2026” are different things. argon2id is the latter.

bcrypt was designed for 1999

bcrypt was published in 1999 by Niels Provos and David Mazières. It was a significant improvement over MD5 and DES-based crypt — the Blowfish-based key schedule made it expensive to brute-force, and the adaptive cost factor meant you could increase iterations as hardware got faster.

Here’s the thing: in 1999, a “fast computer” was a 500 MHz Pentium III. GPUs didn’t exist as general-purpose compute devices. ASICs were a concept from the semiconductor industry, not a consumer product. bcrypt’s threat model was “an attacker with a lot of CPUs.” It solved that problem well.

Then in 2010, Nvidia launched CUDA, and everything changed. A modern GPU can perform billions of SHA-256 hashes per second. Bitcoin mining built an entire industry around ASICs that hash at hundreds of terahashes per second. The threat landscape shifted from “many CPUs” to “specialized hardware that’s orders of magnitude faster and cheaper per hash.”

bcrypt is CPU-hard but not memory-hard. It needs a few kilobytes of memory per hash. A GPU with 24 GB of VRAM can run thousands of bcrypt hashes in parallel without breaking a sweat. The cost factor slows it down, but you’re fighting a hardware arms race by turning a dial — and the dial has a ceiling, because every login also pays that cost.

argon2id was designed for 2015

argon2id is the winner of the Password Hashing Competition (PHC) — a 2013–2015 academic competition that attracted 24 submissions from cryptographers worldwide, evaluated by a panel including Bruce Schneier and Colin Percival. It was designed from the ground up to resist the threat landscape that bcrypt couldn’t anticipate: GPU and ASIC attacks.

The key innovation is memory-hardness. argon2id requires a configurable amount of RAM to compute a single hash. Not a few kilobytes — tens of megabytes. This doesn’t matter on a server doing one login at a time. It matters enormously on a GPU.

A GPU is fast because it has thousands of parallel cores. But it has limited memory bandwidth. If each hash requires 19 MiB of memory, a GPU with 24 GB of VRAM can only run ~1,200 hashes in parallel — and the memory bandwidth becomes the bottleneck, not the compute cores. The GPU’s entire advantage (massive parallelism) is neutralized.

ASICs are worse off. You can build a chip that computes bcrypt hashes at ludicrous speed because bcrypt needs almost no memory. Building an ASIC with 19 MiB of fast SRAM per hash core is economically impractical — the silicon cost per hash skyrockets. Memory-hardness turns a compute problem into a memory problem, and memory is expensive in silicon.

Three knobs, not one

bcrypt has one tunable parameter: the cost factor (iterations). You turn it up as hardware gets faster. That’s it.

argon2id has three:

Memory cost — how much RAM each hash requires. Measured in KiB. This is the primary defense against GPUs and ASICs.
Time cost — how many iterations the memory-hard function runs. More iterations = more passes over the memory buffer.
Parallelism — how many parallel lanes the computation uses. This lets you tune for the number of cores on your server.

This means you can tune argon2id for the hardware you actually run on. If your server has 4 cores and 4 GB of RAM, you pick parameters that make login take ~100ms without starving other processes. If you’re on a 32-core machine with 64 GB, you can afford higher memory cost. bcrypt’s single dial can’t express “use more memory” at all — it doesn’t have that concept.

What Dulak actually uses

Here’s the implementation in src/server/auth.ts:

export const hashPassword = (password: string) =>
  Bun.password.hash(password, {
    algorithm: "argon2id",
    memoryCost: 19456,
    timeCost: 2,
  });

That’s it. No abstraction, no wrapper class, no config file. Bun.password.hash is built into Bun — zero dependencies.

The parameters:

memoryCost: 19456 — 19 MiB per hash. This matches the OWASP-recommended argon2id configuration (m=19456, t=2, p=1 as one of two accepted configurations).
timeCost: 2 — two passes over the memory buffer. OWASP recommends 1–2; Dulak uses 2 for a small additional safety margin.
parallelism: 1 (Bun’s default when not specified) — single-lane computation, appropriate for a web server where logins are sequential per request.

Verification is equally simple:

export const verifyPassword = (password: string, hash: string) =>
  Bun.password.verify(password, hash);

The algorithm and parameters are encoded in the hash string itself ($argon2id$v=19$m=19456,t=2,p=1$...), so verification doesn’t need to be told which parameters were used — it reads them from the hash. This means you can change parameters later and old hashes still verify correctly. You re-hash on next login.

The cost in practice

19 MiB of memory per hash means: if 10 users log in simultaneously, that’s 190 MiB of RAM. On a server with even 1 GB of memory, this is a non-issue. On a $5 VPS with 512 MB, it’s still fine — logins are rare events, not per-request operations.

The time cost: with these parameters, a single argon2id hash takes roughly 50–100ms on modern hardware. That’s the point — password hashing should be slow. A 100ms login delay is invisible to a user and devastating to an attacker trying billions of combinations. bcrypt at cost factor 12 takes a similar amount of time. The difference is that argon2id’s 100ms also consumed 19 MiB of memory, while bcrypt’s 100ms consumed ~4 KB.

When bcrypt is fine

Let’s be clear: if you have an existing system with bcrypt, do not panic-migrate. bcrypt at cost factor 12+ is still resistant to offline attacks with reasonable password entropy. The sky is not falling. Your bcrypt hashes are not “insecure” — they’re just not optimal.

The pragmatic approach for existing systems:

Keep bcrypt for existing hashes.
Use argon2id for new passwords.
When a user with a bcrypt hash logs in, verify with bcrypt, then re-hash with argon2id and update the stored hash.
Over time, your user base migrates naturally — no forced password resets, no downtime.

This is called password hash migration on login, and it’s the standard recommendation. You don’t need a “migration project.” You need one if statement in your verify path.

Why not just use bcrypt with a higher cost factor?

Because turning up bcrypt’s cost factor is a losing game. Every doubling of the cost factor doubles login time for your users and doubles the attacker’s cost per hash. But the attacker has a GPU with thousands of parallel cores — doubling their cost per hash barely matters when they’re running 10,000 in parallel. Meanwhile, your user is now waiting 400ms instead of 200ms for a login.

argon2id’s memory cost scales differently. Increasing memory cost from 19 MiB to 64 MiB doesn’t just make each hash slower — it reduces the number of hashes a GPU can run in parallel by 3.4×, because VRAM is the constraint. You’re not just increasing the cost per hash; you’re reducing the attacker’s throughput. That’s a fundamentally different defense.

The short version

bcrypt for legacy. argon2id for new code.

bcrypt was the right answer in 1999. It’s still an answer in 2026. But if you’re starting a new project, there is no reason to pick the 1999 answer when the 2015 answer exists, is OWASP-recommended, is built into your runtime, and costs you one line of configuration.

Dulak uses argon2id with OWASP-recommended parameters because the alternative is using a hashing algorithm designed before GPUs existed and pretending the last 15 years of hardware evolution didn’t happen.

See the auth and sessions guide for how password hashing fits into the full authentication flow — DB-backed sessions, CSRF protection, and route guards.

JWT is the wrong default. Sessions are the right one

Sat, 08 Aug 2026 00:00:00 GMT

Every auth discussion on the internet goes the same way. Someone says “just use JWT.” Someone else says “no, sessions.” Both sides write 3,000-word blog posts. Nobody ships.

Dulak uses server-side sessions. Not because it’s trendy — because JWT doesn’t solve a problem Dulak has, and it creates several that sessions don’t have.

JWT cannot be revoked

This is the fundamental problem. A JWT is a self-contained token: the server signs it, hands it to the client, and the client sends it back on every request. The server verifies the signature and trusts the claims. There is no server-side record of the token.

So what happens when a user clicks “log out”? The server… can’t do anything. The token is still valid until it expires. You can delete it from the client’s localStorage, but if someone copied it — and tokens are famously easy to steal from localStorage — they still have a valid session.

The standard JWT answer to this is a revocation list: a server-side set of revoked token IDs that you check on every request. Congratulations, you just invented sessions — except worse, because now you have JWT and a database lookup and a revocation list to manage.

Dulak’s session revocation is one line of SQL:

export function deleteSessionByToken(token: string): void {
  deleteSession.run(hashToken(token));
}

That’s a DELETE FROM sessions WHERE token_hash = ?. The row is gone. The next request with that cookie finds nothing and gets redirected to /login. Instant, unconditional, no allowlist or blocklist to maintain.

Refresh token rotation is a Rube Goldberg machine

To work around the revocation problem, JWT-based systems invented refresh tokens. The access token is short-lived (15 minutes), and a separate refresh token is used to get new access tokens. This way, a stolen access token dies quickly.

But now you need:

Token rotation: every refresh produces a new refresh token, invalidating the old one.
Reuse detection: if the old refresh token is used again, it means someone stole it — so you revoke the entire token family.
Token families: a chain of refresh tokens linked by a shared ID, so you can nuke them all on reuse detection.
A server-side store to track which refresh tokens are valid.

You read that last bullet correctly. The “stateless” solution requires server-side state to work securely. The very thing JWT was supposed to eliminate.

Dulak’s session “rotation” is: delete the old session row, insert a new one. This happens on login and registration as a session-fixation defense. Password changes go further — deleteOtherSessionsByToken wipes every session for the user except the current one:

export function deleteOtherSessionsByToken(
  token: string,
  userId: number,
): void {
  deleteOtherSessions.run(userId, hashToken(token));
}

One SQL statement. Every other device is signed out. No token families, no reuse detection, no refresh token flow to debug at 2am.

JWT payload bloat

A JWT has three parts: header, payload, signature — all base64-encoded and sent on every request. The payload contains whatever claims you put in it: user ID, roles, email, maybe permissions.

A minimal JWT payload might be 200 bytes. Add roles, permissions, and metadata and you’re at 500+ bytes. Every. Single. Request. For a page that makes 5 API calls, that’s 2.5KB of token data flying across the wire — parsed, base64-decoded, and signature-verified on every call.

Dulak’s session cookie carries a 64-character hex string: a 256-bit random token. That’s 64 bytes. The server looks up the session row, gets the user_id, and fetches the user. The user data lives server-side — it doesn’t travel with the request.

And since Dulak uses SQLite with WAL mode, that lookup is a primary-key scan on an indexed table. The benchmark: 52,000 reads per second on a single Bun process. The session lookup is not your bottleneck.

The secret rotation headache

JWT requires a signing secret. If that secret leaks, every token ever issued with it is forgeable. So you need to:

Store the secret securely (environment variable, secrets manager).
Rotate it periodically (best practice, they say).
Support multiple secrets during rotation (old tokens verified with old key, new tokens signed with new key).
Decide what algorithm to use (HS256? RS256? what if someone downgrades to none?).

Session tokens are 256 bits of crypto.randomBytes. There is no secret. There is no algorithm. There is no rotation. You generate random bytes, hash them with SHA-256, store the hash. If you want to invalidate all sessions, you truncate the sessions table. No key management, no algorithm migration, no “alg: none” attack vector.

Dulak’s token generation is three lines:

export function createSession(userId: number): SessionInfo {
  const token = randomBytes(32).toString("hex");
  const expiresAt = new Date(Date.now() + SESSION_TTL_MS);
  insertSession.run(hashToken(token), userId, expiresAt.toISOString());
  return { token, expiresAt };
}

No signing key. No algorithm. No rotation ceremony. Random bytes in, hash out, row inserted.

The “stateless” myth

JWT is marketed as “no server state.” This is the selling point. No session table, no database lookup, no server-side storage. Just sign and verify.

Here’s what actually happens in production:

You need revocation (log out, password change, compromised token) → you add a revocation list. Server state.
You need to check if a user is banned or their role changed → you can’t trust the JWT payload anymore, so you do a database lookup. Server state.
You need refresh token rotation → you track valid refresh tokens server-side. Server state.

You end up with JWT plus a database lookup plus a revocation list. You have all the complexity of sessions and all the complexity of JWT. The “stateless” promise evaporated the moment you had a real product with real security requirements.

Dulak skips the JWT layer entirely. Every request does one session lookup and one user lookup — both primary-key queries on SQLite, both sub-millisecond. That’s the same cost as the JWT revocation check, except the architecture is simpler and revocation actually works.

“But why not cache the session lookup?”

A reasonable question: if every request does two SQLite PK lookups, wouldn’t an in-memory cache make it faster? Benchmarked on an M4 with 100K users and 100K sessions in SQLite WAL mode:

Path	Cost/req	Ops/sec	vs no cache
No cache (hash + 2 PK scans)	1.73µs	578K	baseline
Full cache (token → user in a `Map`)	0.35µs	2.87M	5× faster
Session cache (token → session in a `Map`, still fetch user)	0.95µs	1.05M	1.8× faster

The full cache is 5× faster. It’s also a trap.

Remember the stale-payload problem from the last section — “you can’t trust the JWT payload anymore” when a role changes or a user is banned? A token → user cache has the exact same problem. The cached user row goes stale the moment an admin bans the account or changes a role. To stay correct you need cache invalidation: evict on logout, evict on role change, evict on ban, evict on password change, add a TTL safety net. That is a revocation list — the very complexity this architecture exists to avoid. You’d be trading 1.38µs per request for the bug surface JWT was rejected for.

The session-only cache (1.8× faster) is the safe middle ground — user data stays fresh, only the session row is cached. But 0.77µs saved per request doesn’t justify the invalidation logic and memory overhead.

And there’s a deeper point: SQLite with WAL mode already keeps hot B-tree pages in the OS page cache. The benchmark proves it — scaling from 10K to 100K rows added only 0.09µs (5.5%). If those lookups were disk-bound, 10× the data would be far slower. Near-constant cost means the pages are already in RAM. A JavaScript Map on top of the OS page cache is a cache on top of a cache, with invalidation burden and no real I/O to save.

At 1.73µs per request, auth lookup consumes under 0.3% of a core at 1K req/sec. The bottleneck is network, TLS, SSR rendering, business logic — never the session row. The session lookup is not your bottleneck, and caching it would cost you the one property that makes sessions worth choosing over JWT: revocation that actually works.

How Dulak’s sessions actually work

The full picture, from src/server/auth.ts:

Token: 256-bit random bytes (randomBytes(32)), stored as a 64-char hex string in the cookie.
At rest: only the SHA-256 hash of the token is stored in the sessions table. A database leak cannot expose valid tokens — the raw token never touches disk.
Cookie: httpOnly (no JavaScript access), SameSite=Lax (CSRF baseline), Secure in production, 30-day expiry.
Lookup: resolveUser(token) hashes the cookie token, finds the session row, lazily deletes expired sessions, and returns the user.
Revocation: DELETE FROM sessions WHERE token_hash = ?. One row, one statement, done.
Rotation: new session on login/register (session-fixation defense). Password change wipes other devices.
Flash messages: one-shot messages stored on the session row (sessions.flash), consumed on render. No separate flash store.

The schema is four columns:

CREATE TABLE sessions (
  token_hash TEXT PRIMARY KEY,
  user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  flash      TEXT    NOT NULL DEFAULT '{}',
  expires_at TEXT    NOT NULL,
  created_at TEXT    NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ', 'now'))
);

That’s it. No token families, no refresh token table, no revocation list, no signing key rotation schedule.

When JWT actually makes sense

JWT isn’t evil. It has legitimate use cases:

Federated identity / SSO: when one service issues tokens that another service consumes, and the two services don’t share a database. JWT’s signed claims make sense here.
Short-lived authorization between microservices: a service-to-service token that lives for 30 seconds and doesn’t need revocation.
OAuth/OIDC: Dulak uses Google OAuth, and OAuth uses JWT-style tokens internally. That’s fine — it’s a different problem domain.

None of these are “user authentication in a single-process app with a database.” That’s Dulak’s problem, and sessions solve it with less code, less complexity, and revocation that actually works.

The short version

Sessions are one row in SQLite. Delete the row, the session is gone.

JWT gives you a signed token you can’t revoke, a payload that bloats every request, a secret you have to rotate, and a “stateless” architecture that needs server state the moment you ship a real product. Sessions give you a cookie, a database lookup, and a DELETE statement.

Read the full session and guard implementation in the sessions & guards docs.

Laravel is good. Your next project should not use it

Sat, 08 Aug 2026 00:00:00 GMT

Laravel is a good framework. It’s well-documented, has a thriving ecosystem, and has shipped thousands of production apps. This is not a hit piece. This is a case for why your next project should not be one of them.

The four-toolchain tax

Laravel doesn’t run on one thing. It runs on four:

PHP — the language and runtime
Composer — the package manager
A web server — Nginx, Apache, or FrankenPHP (which is itself a Go binary embedding PHP)
A database driver — PDO MySQL, PDO PostgreSQL, or the SQLite driver

Each of these has its own version, its own configuration, its own upgrade cycle, and its own breaking changes. When you deploy a Laravel app, you’re maintaining four toolchains. When one of them releases a breaking change — PHP 8.4 deprecates something, Composer v3 changes resolution behavior, Nginx updates its config syntax — you’re debugging the intersection.

Dulak runs on one runtime: Bun. Bun is the HTTP server, the database engine (bun:sqlite), the bundler, the test runner, and the package manager. One install, one version, one upgrade. The web server is built in. The database is built in. There is no second toolchain to configure.

The SSR tax

Laravel’s Inertia SSR — the feature that lets you render React or Vue on the server — requires a separate Node.js process. You’re running PHP and Node to serve one application. Two runtimes, two process managers, two sets of environment variables, two things that can crash independently.

Dulak renders SSR in the same Bun process as the HTTP server and the database. renderToString runs inside the Hono handler, in the same event loop that serves the request. No second runtime, no IPC, no separate deployment. One process does everything.

If you want Inertia SSR in Laravel, you need Node installed on your production server alongside PHP. If you want SSR in Dulak, you need nothing — it’s already running.

The ORM tax

Eloquent is a full-featured ORM. It has model hydration, collections, query builders, relationships, scopes, accessors, mutators, and event dispatch. It’s impressive. It’s also 8× slower than raw SQL.

The numbers, from the benchmark page:

Endpoint	Dulak (Hono+Bun)	Laravel (FrankenPHP, 8 workers)	Dulak faster
`GET /health` (no DB)	65,807 req/s	6,237 req/s	10.5×
`GET /users/:id` (PK read)	51,934 req/s	6,391 req/s	8.1×
`GET /users?limit=20` (list)	32,222 req/s	4,734 req/s	6.8×
`DELETE /users/:id` (delete)	27,744 req/s	5,655 req/s	4.9×

Laravel’s health check (6,237 req/s) and DB point read (6,391 req/s) are nearly identical — the database adds no measurable overhead because ~7ms of framework overhead dwarfs the ~0.1ms SQLite query. The framework is the bottleneck, not the database.

Dulak uses raw SQL prepared statements. No model hydration, no collection wrapping, no event dispatch. The query plan is compiled once at module load and reused for every request. You see the exact SQL that runs. The AI writing your next feature writes it at peak performance — no abstraction layer to generate through.

TypeScript everywhere

Laravel developers write PHP on the server and JavaScript on the client. Two languages, two type systems, two mental models, two sets of tooling. Every feature requires context-switching between PHP and JS. Every shared type is manually synced — a User model in Eloquent and a User interface in TypeScript, kept in sync by hope and code review.

Dulak is TypeScript end to end. Server, client, shared types — all in src/shared/types.ts. The User type that the database returns is the same User type the React component receives. No sync, no drift, no duplicate definitions.

In 2026 where AI generates code, having one language means the AI is always in context. It doesn’t switch between PHP mode and JavaScript mode. It doesn’t forget the shape of a model because it was defined in a different language. One language, one type system, one context window.

The deployment complexity

A production Laravel deployment looks like this:

Install PHP + Composer
Install and configure a web server (Nginx or FrankenPHP)
Configure PHP-FPM (or Octane for persistent workers)
Run composer install --no-dev --optimize-autoloader
Set up environment variables (.env)
Configure a queue worker (Supervisor + php artisan queue:work)
Configure a scheduler (cron + php artisan schedule:run)
If you want SSR: install Node, configure the Inertia SSR server, manage it as a separate process
Configure a reverse proxy to route to PHP-FPM or FrankenPHP

A production Dulak deployment looks like this:

bun run start

Or with Docker:

docker compose up -d

One process. One binary. The queue worker, the scheduler, the SSR server — they don’t exist as separate things to manage. If you need a background job, you write a function and call it. If you need SSR, it’s already running. The entire deployment is one process that does everything.

The 2026 angle

Here’s the argument that matters most: PHP was a great language for 2005. It was easy to learn, easy to deploy (upload files to a server), and had a massive ecosystem. The language barrier — “I already know PHP” — kept developers in the Laravel ecosystem for decades.

In 2026, that barrier is gone. AI writes code in whatever language you ask. TypeScript is as easy to generate as PHP. The question “but who will maintain the TypeScript?” has the same answer as “but who will maintain the PHP?” — the AI will, and it’s equally fluent in both.

So the remaining question is: which ecosystem gives you less infrastructure to manage?

Laravel: 4 toolchains, 2 languages, 2 runtimes for SSR, a queue worker, a scheduler, a web server, a database driver.
Dulak: 1 runtime, 1 language, 1 process, 1 binary.

The answer is not subtle.

When to stay with Laravel

This is not a “rewrite everything” argument. If you have:

An existing Laravel app with years of code — don’t rewrite. The switching cost is real, and Laravel is a fine framework for maintaining what you have.
A team deep in PHP expertise — switching to TypeScript + Bun has a learning curve. If your team is fast and happy in Laravel, the productivity cost of switching may not be worth it.
Laravel-specific packages you depend on — Nova, Horizon, Telescope, Filament, Livewire. These are genuinely good tools with no Dulak equivalents. If your app is built on them, Dulak is not a drop-in replacement.

This is about what to start new projects in. When you’re choosing a stack for a greenfield app in 2026, the question is not “which framework do I know?” — AI knows all of them. The question is “which stack gives me the least infrastructure to wire, the fewest toolchains to maintain, and the fastest path from zero to business logic?”

That’s Dulak.

The short version

Laravel for existing apps. Dulak for new ones.

The numbers: 8× slower on reads, 5× slower on writes. The toolchains: 4 vs 1. The runtimes for SSR: 2 vs 1. The languages: 2 vs 1. The deployment: 8 steps vs 1 command. See the full comparison for the detailed breakdown.

Next.js is the default. It should not be

Sat, 08 Aug 2026 00:00:00 GMT

Next.js is the default React framework. It has excellent docs, a massive ecosystem, and Vercel’s marketing machine behind it. If you type “React starter” into any search engine, Next.js is the answer. This is not a hit piece — it’s a case for why your next React app should not be built on it.

The runtime tax

Next.js doesn’t run on one thing. It runs on several:

Node.js — the runtime, version-managed separately from your code
A package manager — npm, yarn, or pnpm, each with its own lockfile format and resolution behavior
A build pipeline — webpack or Turbopack, with config files layered on top (next.config.js, tsconfig.json, PostCSS config, ESLint config, Tailwind config)
A deployment target — Vercel’s serverless platform, or a self-hosted Node server you configure yourself

Each of these has its own version, its own config, its own upgrade cycle. Next.js itself releases a new version every few months; each one can change the router, the build output, or the config format. When you upgrade, you’re not upgrading one thing — you’re upgrading the intersection of Node, the bundler, and the framework.

The React Server Components tax

Next.js’s App Router is built on React Server Components. RSC is a genuinely clever idea — render components on the server, stream the result, hydrate on the client. But it comes with a mental-model tax that has no equivalent in a plain React app:

'use client' boundaries. Every component that touches state, effects, or browser APIs needs the directive. Every library that isn’t RSC-aware needs a wrapper. You spend real time deciding which side of the boundary each component lives on — and re-deciding when you move a component and the tree breaks.
Two render passes. The server renders the component tree, then the client hydrates it. Two executions of the same components, two chances for a mismatch, one invisible bug that only shows up in production.
Serialization limits. Props crossing the server/client boundary must be serializable — no functions, no class instances, no Date in some cases. Data fetching looks local (await db.query() in a component) but isn’t, which confuses both humans and AI.

Dulak’s Inertia rendering has none of this. The server renders HTML with react-dom/server; the client calls hydrateRoot and attaches event listeners. One render pass, one component tree, no 'use client', no boundary to reason about. Props are the page payload — serializable by definition.

The framework overhead tax

Next.js is a large framework. Before your component renders, the request travels through the Next.js router, the RSC runtime, the data cache, the client reference registry, and the streaming layer. That machinery has a measurable cost per request.

Dulak’s HTTP layer is Hono — a zero-overhead router on top of Bun’s native server. The benchmark numbers show what framework overhead looks like when it’s small: the no-DB health check does 66K req/s, and a SQLite point read adds just 0.2ms. The framework is not the bottleneck — because there isn’t much framework.

The Next.js equivalent: a framework that re-renders your components on two runtimes, with a build pipeline, a cache layer, and a middleware runtime — before your code even runs. Every request pays for all of it.

The deployment tax

Next.js deployment means choosing between two paths, both expensive:

Vercel (the default). The frictionless path is the proprietary one. Your app runs on Vercel’s serverless functions, with Vercel’s caching, Vercel’s edge network, and Vercel’s pricing. Moving off later means rewriting the deployment — the “works on Vercel” configuration doesn’t transfer.
Self-hosted. You configure a Node server, run next start, set up a process manager, a reverse proxy, environment variables, and the build pipeline. Static pages, ISR, and serverless functions each need their own serving strategy. This is a real project, not a command.

A production Dulak deployment is one command:

bun run start

Or with Docker:

docker compose up -d

One process, one binary, no platform to migrate off later. The app runs anywhere Bun runs — a VPS, a Docker host, a Raspberry Pi. There is no “deploy target” to escape.

The 2026 angle

Here’s the argument that matters most: framework complexity is now pure cost. In 2016, a framework like Next.js earned its complexity by making SSR accessible — you didn’t have to wire Webpack, Babel, and a server by hand. The abstraction was paying for itself.

In 2026, AI writes the code. Wiring the bundler, configuring the router, and translating intent into 'use client' boundaries are tasks an AI does — but it does them around the framework, not because of it. The complexity doesn’t disappear; it becomes something the AI has to navigate in every session. Every Next.js-specific concept — RSC boundaries, serialization limits, cache semantics, middleware runtimes — is context the AI must load, reason about, and avoid tripping over.

The question is no longer “what does this framework do for me?” It’s “how much does this framework make the AI maintain, and is that complexity earning its keep?” For Next.js, the answer is a lot of maintenance and a thin earning.

When to stay with Next.js

This is not a “rewrite everything” argument. If you have:

An existing Next.js app with years of code — don’t rewrite. The switching cost is real, and Next.js is a fine framework for maintaining what you have.
A team deep in the Next.js ecosystem — if your team ships fast in the App Router, the productivity cost of switching may not be worth it.
A need for the framework’s opinionated conventions — file-based routing, next/image optimization, built-in fonts. These are genuinely useful. If your app leans on them, Next.js is not a bad choice.

This is about what to start new projects in. When you’re choosing a stack for a greenfield app in 2026, the question is not “which framework has the most features?” — AI can wire any of them. The question is “which stack leaves me the least to configure, the fewest boundaries to reason about, and the fastest path from zero to business logic?”

That’s Dulak: Hono + Inertia on Bun. One runtime, one render pass, one process, no 'use client'.

The short version

Next.js for existing apps. Dulak for new ones.

The runtimes: 2+ (Node + build pipeline) vs 1. The render passes: 2 (RSC) vs 1. The component boundaries: 'use client' everywhere vs none. The deploy target: Vercel or self-hosted Node vs one binary. The complexity the AI must navigate: the entire framework vs one event loop.

Node needs 5 tools. Bun ships one

Sat, 08 Aug 2026 00:00:00 GMT

Every Node.js project starts the same way: a package.json, then a dependency list that grows like a fungus. HTTP server, package manager, test runner, bundler, database driver — five separate tools, five separate config files, five things to keep in sync. By the time your app boots, you’ve spent an afternoon reading setup docs.

Dulak runs on Bun. One binary. One runtime. Zero config files for the toolchain. Here’s why that matters.

The Node toolchain tax

A production Node.js web app needs all of these:

Concern	Node tool	Config file
Package manager	npm / pnpm / yarn	`package.json`, `pnpm-workspace.yaml`, `yarn.lock`
HTTP server	Express / Fastify / native `http`	`tsconfig.json` (if TS), framework config
Test runner	Jest / Vitest / Mocha	`jest.config.js`, `vitest.config.ts`
Bundler	Webpack / Vite / esbuild	`webpack.config.js`, `vite.config.ts`
Database driver	`pg` / `mysql2` / `better-sqlite3`	connection pool config, env vars

That’s five tools. Five things to install. Five things to upgrade. Five things that can break independently. Five release cycles to track. Five opportunities for a breaking change to land on a Tuesday morning and ruin your sprint.

Each one also brings its own dependency tree. jest alone pulls in 40+ packages. webpack has 60+ plugins you’ll need to configure. Your node_modules directory is a small village of code you didn’t write, can’t audit, and don’t control.

This isn’t a knock on any individual tool. Express is fine. Jest is fine. Vite is fine. The problem is the aggregation — five separate ecosystems, each with its own maintainers, release cadence, and opinions about how things should work. The more moving parts, the more ways they disagree.

Bun is one binary

Bun ships everything in a single executable:

Concern	Bun built-in	Config file
Package manager	`bun install`	`bun.lock` (auto-generated)
HTTP server	`Bun.serve()`	none
Test runner	`bun test`	none
Bundler	`Bun.build()`	none
Database	`bun:sqlite`	none

One install. One runtime. Zero config files for the toolchain itself. Dulak’s entire server entry point is this:

const server = Bun.serve({
  port,
  fetch: createApp(assets).fetch,
});

That’s it. No Express app factory, no middleware registration ceremony, no app.listen(). Bun.serve takes a port and a fetch handler. Hono provides the handler. The server is running.

The database is equally simple:

import { Database } from "bun:sqlite";
const db = new Database("app.sqlite");

No npm install better-sqlite3. No native compilation step. No node-gyp. bun:sqlite is compiled into the Bun binary — it’s a native binding to SQLite, not a JavaScript wrapper around a C library you have to build yourself.

The test runner needs no config either:

import { describe, expect, it } from "bun:test";

bun test discovers test files, runs them, reports results. No jest.config.js. No vitest.config.ts. No transform pipeline. Dulak’s 67-test E2E suite runs with bun test --isolate — one flag, one command, done.

The bundler is the same story. Dulak builds client assets with Bun.build:

const result = await Bun.build({
  entrypoints: ["src/client/app.tsx"],
  outdir: "dist/assets",
  target: "browser",
});

No webpack.config.js. No vite.config.ts. No plugin chain. One function call, content-hashed output, done.

Performance: the numbers

Bun isn’t just simpler — it’s faster. Dulak’s full-stack benchmarks measure the complete HTTP path: Hono routing, bun:sqlite queries, JSON serialization, 50 concurrent workers.

Endpoint	req/s	p50 latency
Health check (no DB)	65,807	0.76ms
Point read (`GET /users/:id`)	51,934	0.82ms
Delete (`DELETE /users/:id`)	27,744	1.41ms

The health check — pure HTTP, no database — hits 66K req/s. The database point read hits 52K req/s. The database adds only 0.2ms to a 0.76ms HTTP base. The framework is so lean that the database query is a visible fraction of total request time, not buried under framework overhead.

For comparison, Laravel 13.24 on FrankenPHP (8 workers — the fastest production PHP server for Laravel) hits 6,237 req/s on the same health check. That’s 10.5× slower than Bun on the no-database endpoint. On the database point read, Laravel hits 6,391 req/s — 8.1× slower. The gap isn’t the database; it’s the runtime and framework overhead.

Bun’s HTTP server is built on uSockets — a C library that handles TCP, TLS, and HTTP parsing at near-kernel speed. Node’s http module is JavaScript all the way down. The difference shows up in every request.

bun:sqlite has no driver overhead either. Node’s better-sqlite3 is a native addon, but it still crosses a V8 ↔ native boundary per call. bun:sqlite is compiled into Bun’s binary — the SQLite C library and Bun’s JavaScript engine share the same process, same memory, same event loop. Zero serialization, zero copy, zero IPC.

TypeScript: no compilation step

Node’s relationship with TypeScript in 2026 is… improving. Node 22.6+ ships --experimental-strip-types, which strips type annotations at runtime. It works, but it’s experimental, it doesn’t do type checking, and you’re still passing a flag.

Before that, you needed ts-node, or tsx, or a build step with tsc, or a bundler that transpiles. Each option adds a dependency and a configuration decision. tsconfig.json alone is a 40-line file with 30 options, and if you get one wrong, your imports silently break.

Bun runs TypeScript natively. No flag. No ts-node. No compilation step. No tsx. You write .ts files, you run bun src/index.ts, it works. Type checking is a separate concern — tsc --noEmit in CI — but the runtime doesn’t care about your types. It just runs the code.

Dulak’s package.json has "typecheck": "tsc --noEmit" as a separate script. Type errors are caught in CI, not at runtime. The runtime executes JavaScript; the types are a development-time contract. This is the correct separation of concerns — and Bun makes it the default, not something you configure.

The toolchain tax, quantified

Let’s count the things you don’t maintain when you pick Bun over Node for a Dulak-style app:

No jest.config.js — bun test has sensible defaults
No vite.config.ts or webpack.config.js — Bun.build is a function call
No better-sqlite3 native build — bun:sqlite is in the binary
No ts-node / tsx — Bun runs TypeScript directly
No nodemon — bun --watch is built in
No cross-env — Bun handles env vars consistently across platforms

That’s six dependencies and six config files you never create. Six things that never break. Six upgrade cycles you never track. Six entries in your package.json that don’t exist.

Dulak’s package.json has four runtime dependencies: hono, @inertiajs/react, react, react-dom. Plus @sinclair/typebox for validation. That’s it. No HTTP framework config, no test runner config, no bundler config, no database driver. The toolchain is the runtime.

When Node still makes sense

This isn’t a religious argument. Node has legitimate advantages:

Existing infrastructure — if your company has Node deploys, monitoring, and on-call runbooks wired up, switching runtimes has a real cost. Don’t rewrite for the sake of it.
Specific npm packages — most npm packages work with Bun (Bun implements the Node API), but some don’t. If your app depends on a package that uses Node-specific internals Bun doesn’t support, Node is the safer choice.
Edge runtime requirements — Cloudflare Workers, Vercel Edge, and Deno Deploy use V8-based or custom runtimes. If you’re deploying to the edge, Node compatibility matters more than Bun’s toolchain consolidation.
Team expertise — if your team knows Node deeply and has no Bun experience, the learning curve is real. It’s small (Bun’s API is simpler), but it’s nonzero.

Dulak is a starting point. If you’re starting fresh, Bun eliminates a class of problems you’d otherwise spend time solving. If you’re integrating into an existing Node ecosystem, the toolchain tax is already paid — and switching may not be worth it.

The short version

Node is five toolchains pretending to be one. Bun is one binary that actually is one.

The Node ecosystem’s answer to “why do I need five tools?” is “because each one is best-in-class.” Maybe. But best-in-class tools that don’t know about each other still produce a config file per tool, a dependency tree per tool, and a breaking change per tool per quarter.

Bun’s answer is: the runtime should be the toolchain. HTTP server, database, test runner, bundler, package manager, TypeScript — all one binary, all one install, all one upgrade. Dulak serves 52K reads/s and 95K writes/s on a single process with four runtime dependencies. That’s what “no abstraction tax” looks like in practice.

Pick Node if you have to. Pick Bun if you can.

ORMs are dead in 2026. AI killed them

Sat, 08 Aug 2026 00:00:00 GMT

Every boilerplate in the TypeScript ecosystem ships an ORM. Prisma, Drizzle, TypeORM, MikroORM — pick your poison. So when people see that Dulak has zero ORM dependencies and every query is raw SQL in db.ts, the reaction is predictable: “That doesn’t scale. You’ll regret this.”

Let’s talk about why that’s wrong, and why the ORM question in 2026 is fundamentally different from the ORM question in 2015.

The problem ORMs solved is gone

Here’s the thing nobody says out loud: ORMs were never about performance. They were about human friction. Writing SQL by hand was painful — you had to know the syntax, remember the join types, get the escaping right, and deal with the fact that your database spoke a different language than your application code. ORMs let you write TypeScript instead of SQL, and that was genuinely valuable when the alternative was string-concatenating queries in a text editor.

In 2026, that value proposition has collapsed. AI generates correct, optimized raw SQL on demand. You describe what you want — “get the 10 most recent users with their session count” — and you get back a query with the right joins, the right indexes, and the right LIMIT. The AI doesn’t need an ORM to translate your intent into SQL. It writes SQL directly, because SQL is the language the database actually speaks.

And here’s the deeper point: this isn’t just about SQL. In 2026, code is AI-generated. The entire category of “abstractions that make humans more productive” — ORMs, query builders, template engines, utility CSS frameworks — exists to reduce human friction. When code is free to produce, that friction disappears. What’s left is the question you should have been asking all along: does this abstraction make my code faster, or slower? ORMs make it slower. They add a translation layer between your intent and the database. In a world where AI writes raw SQL at peak performance, accepting that translation layer is paying a tax for a service nobody is rendering anymore.

What remains is the cost

An ORM is a dependency. Dependencies have a lifecycle, and it’s never free:

You upgrade it. Prisma had four major versions in four years. Each one changed the schema syntax, the query API, or the migration format. Every upgrade is a project.
You audit it. An ORM that generates SQL is a code generator running in your production process. When a query is slow, you have to figure out what SQL the ORM actually generated — which means enabling query logging, reading the output, and mapping it back to the ORM method chain that produced it.
You debug it. When the ORM’s eager-loading strategy produces an N+1 query (more on that below), you’re debugging two layers: your application logic and the ORM’s loading strategy. The ORM is a black box between you and the database.

None of this is the ORM’s fault — it’s the inherent cost of an abstraction layer. The question is whether the abstraction earns its cost. In 2026, with AI writing your SQL, it doesn’t.

The N+1 problem is an ORM problem

Here’s a pattern every ORM user has lived through:

// Looks fine. Runs fine in dev with 5 users.
const users = await User.findMany();
for (const user of users) {
  const sessions = await user.sessions(); // ← N+1
}

Five users, five extra queries. In production with 10,000 users, that’s 10,001 queries for a single page load. The ORM made the wrong thing easy — iterating over a relationship looks natural, so you do it without thinking about the query count.

Every ORM has a fix for this — include, with, eager, populate — but the fix is ORM-specific syntax you have to learn, and the default behavior is always the dangerous one. The ORM optimizes for developer convenience at the call site, not for query efficiency at the database.

Raw SQL makes joins explicit:

SELECT u.id, u.name, u.email, COUNT(s.token_hash) AS session_count
FROM users u
LEFT JOIN sessions s ON s.user_id = u.id
GROUP BY u.id
ORDER BY u.id DESC
LIMIT 10;

One query. You can see it’s one query because it is one query. There’s no hidden loading strategy, no lazy evaluation, no “did I remember to eager-load this relationship?” The SQL is the query plan.

Migrations: explicit vs. generated

ORMs ship migration generators. You change your model file, run a command, and the ORM diffs the old schema against the new one and produces a migration. It sounds great until you see what it generates.

ORM-generated migrations are conservative by design — they don’t know your intent, so they do safe things. Want to rename a column? The ORM sees “column dropped, column added” and generates a DROP COLUMN + ADD COLUMN. Your data is gone. You have to manually rewrite the migration to do ALTER TABLE ... RENAME COLUMN, assuming your database even supports it.

Dulak’s migrations are hand-written SQL, versioned, and applied in a transaction. You can see the schema migration guide for the full pattern, but the shape is simple:

-- migrations/0003_add_user_avatar.sql
ALTER TABLE users ADD COLUMN avatar_url TEXT;

That’s it. You wrote the SQL. You know what it does. The migration runner applies it in a transaction — if it fails, the database rolls back and the app doesn’t start. No generator to second-guess your intent, no auto-generated migration that drops a column you wanted to rename.

What Dulak actually does

Open src/server/db.ts and you’ll see the entire database layer. It’s prepared statements, prepared once at module load, typed with TypeScript generics:

export const findUserByEmail = db.query<UserRow, [string]>(
  `SELECT id, name, email, password_hash AS passwordHash, role,
          google_id AS googleId, avatar_url AS avatarUrl,
          created_at AS createdAt
   FROM users WHERE email = ?`,
);

export const createUser = db.query<{ id: number }, [string, string, string]>(
  `INSERT INTO users (name, email, password_hash) VALUES (?, ?, ?) RETURNING id`,
);

Every query in the application is defined here. The SQL is right there in the source — you can read it, copy it into a SQLite shell, run EXPLAIN QUERY PLAN on it, and see exactly what the database will do. No logging required, no query inspector, no “what did the ORM generate?” debugging session.

The TypeScript generics give you type safety on the result shape and the parameter tuple. findUserByEmail takes a string and returns a UserRow. The compiler checks both. This is the same type safety an ORM provides — except it’s zero-dependency and the types describe the actual SQL, not an ORM model that generates SQL.

bun:sqlite is synchronous, so there’s no await on every query, no promise chain, no event loop scheduling overhead. The query runs, returns, you move on. SQLite is in-process — the query is already done by the time you’d schedule a microtask. Async database drivers exist for network-attached databases where the query might take 50ms over the wire. That’s not this.

When an ORM is the right call

The old answers don’t survive contact with 2026. Here are the reasons ORMs were recommended, checked against the world AI created:

“Large teams with varying SQL literacy.” The ORM was a standardization layer for humans who didn’t know SQL. In 2026, humans aren’t writing the SQL — the AI is, and it writes SQL correctly in every dialect. A consistent query interface is now a code-review convention or a lint rule, not a runtime dependency. This argument collapses.
“Switching databases mid-project.” This was always weaker than it sounded: ORMs abstract some dialect differences and leak the rest — types, migrations, transactions, indexes. In 2026 the switch is cheaper without an ORM: “port db.ts to Postgres” and the AI rewrites the queries in the new dialect. Same task an ORM migration would have been, minus the ORM.
“Dynamic query builders.” This one has a kernel of truth — a search page with 15 optional filters does need composable WHERE clauses. But it needs a query builder (kysely, or a 20-line helper that appends conditions), not an ORM. “Dynamic queries” justified the query builder, never the ORM. And in 2026, the AI can generate the conditional SQL itself.

None of these apply to Dulak’s scope: a known schema, a single database, queries that don’t change shape at runtime. An ORM would be paying a tax for features we don’t use — and the one feature it was for (humans writing SQL) is no longer rendered by anyone.

The short version

ORMs solved the problem of humans writing SQL. AI writes SQL now. What’s left is the cost: a dependency, an abstraction layer, and a debugging black box between you and your data.

Dulak’s database layer is db.ts — prepared statements, typed with generics, zero dependencies. You see the SQL. The AI writing your next feature sees the SQL. The database sees the SQL. Everyone is looking at the same thing, and that thing is the actual query plan.

When you outgrow SQLite and swap to Postgres, you replace db.ts with a Postgres driver and update the SQL syntax. No ORM migration, no model layer to rewrite, no abstraction to fight through. The performance numbers don’t change because the bottleneck was never the query layer — it was always the network hop you added by choosing a server database.

PM2 is a band-aid. Bun doesn't need it

Sat, 08 Aug 2026 00:00:00 GMT

If you’re coming from the Node.js ecosystem, PM2 is probably muscle memory. You deploy, you run pm2 start app.js, you move on. It works. So why doesn’t Dulak recommend it?

PM2 solves a Node problem

PM2 was built to manage Node.js processes — restart on crash, handle logs, manage cluster mode. It’s a good tool for Node.

Dulak runs on Bun. Bun is not Node. Using PM2 to manage a Bun process is using a Node tool to manage a non-Node process. It works — PM2 can manage any process — but you’re carrying a dependency that was designed for a different runtime.

systemd already does this

Every Linux server has systemd built in. No install, no dependency, no extra runtime. Dulak’s VPS deployment guide ships a systemd unit file that:

Restarts the process on crash (Restart=always)
Handles graceful shutdown via SIGTERM (Dulak drains in-flight requests and closes the DB)
Manages logs via journald
Starts on boot (WantedBy=multi-user.target)

PM2 duplicates every one of these features. The difference is systemd is already there and PM2 is a dependency you install.

Docker already does this

If you’re deploying with Docker — and Dulak ships a multi-stage Dockerfile — the container runtime handles restarts:

services:
  app:
    restart: unless-stopped

That’s it. No PM2 inside the container, no process manager layer. Docker restarts the container if it exits. Dulak handles SIGTERM for graceful shutdown.

The philosophy angle

Dulak’s philosophy is “zero-dependency where cheap.” systemd is zero-dependency — it’s already on every Linux server. Docker is zero-dependency for containerized deploys — the runtime handles it.

PM2 is a dependency you install to solve a problem that’s already solved. It adds:

A Node.js runtime (to run PM2 itself, even though your app runs on Bun)
A configuration layer (ecosystem.config.js)
A CLI tool to learn and debug
Another thing that can break

When PM2 makes sense

To be fair, PM2 has legitimate use cases:

You’re on a shared host without systemd access — some budget VPS providers restrict systemd. PM2 works without it.
You’re migrating a Node.js app and already have PM2 infrastructure — if your team knows PM2 and your monitoring is wired to it, switching has a cost.
You need cluster mode for a Node app — PM2’s cluster mode is genuinely useful for Node.js multi-core scaling.

None of these apply to Dulak. Dulak is Bun, not Node. Dulak ships with systemd and Docker configs. Dulak handles SIGTERM gracefully.

The short version

systemd for bare metal. Docker for containers. PM2 for Node.

Dulak is not Node.

SQLite beats Postgres — we benchmarked it

Sat, 08 Aug 2026 00:00:00 GMT

Every boilerplate comparison eventually reaches the database question: “Why SQLite? Shouldn’t a production app use Postgres or MySQL?”

It’s a fair question — and the answer isn’t “SQLite is better than Postgres.” It’s “SQLite is the right starting database, and Dulak is a starting point.”

Zero infrastructure

Postgres and MySQL are servers. They run as separate processes, listen on ports, require connection pools, and need credentials managed. Before you write a single query, you need to:

Install the database server
Configure it (memory, connections, WAL, replication)
Create a database and user
Set up credentials (env vars, secrets manager)
Wire a driver into your app (pg, mysql2, etc.)
Configure a connection pool

SQLite is a file. bun:sqlite is built into Bun. There is no step 1.

import { Database } from "bun:sqlite";
const db = new Database("app.sqlite");

That’s the entire setup. No server process, no port, no credentials, no driver dependency, no connection pool. The database is a file on disk.

Fast enough for most apps

Dulak ships with four PRAGMAs that make SQLite fast:

db.exec("PRAGMA journal_mode = WAL");
db.exec("PRAGMA synchronous = NORMAL");
db.exec("PRAGMA busy_timeout = 5000");
db.exec("PRAGMA foreign_keys = ON");

With these settings, Dulak serves 52,000 reads per second through the full HTTP stack (point read, GET /users/:id) and 19,600 creates per second (POST /users, also via HTTP). Drop the HTTP layer and raw bun:sqlite reaches 526,000 reads/s and 95,000 writes/s — the engine ceiling, not what your users experience. For comparison, the no-database health check hits 66K req/s. The database adds only 0.2ms to a 0.76ms HTTP base.

Most apps never reach 1,000 req/s. SQLite handles 52× that on a laptop. The “SQLite is slow” reputation comes from default settings (rollback journal + FULL synchronous mode) that run at 3.5K writes/s — 27× slower than WAL + NORMAL.

Faster than Postgres/MySQL on a single server

This is the part that surprises people: on a single server, SQLite is always faster than Postgres or MySQL for raw query latency. Not sometimes — always. Four reasons:

No network hop — Postgres/MySQL require a TCP round-trip per query, even on localhost (0.5–1ms). SQLite reads from a memory-mapped WAL file in the same process. Zero network latency.
No connection pool overhead — Postgres/MySQL need a pool (acquire/release per query). SQLite uses a single in-process handle with prepared statements cached at module load.
No wire protocol — Postgres/MySQL serialize query text → binary → decode result rows over a wire protocol. SQLite reads pages directly from an mmap’d file into native structs via Bun’s native binding. Zero copy.
No IPC context switch — Postgres/MySQL run as separate server processes. Every query crosses a process boundary. SQLite runs in-process, on the same event loop as your HTTP server.

Postgres and MySQL only win when you need things SQLite fundamentally cannot provide: multi-server horizontal scaling, concurrent parallel writers, or a more sophisticated query optimizer for very large datasets. On a single server with a single app process, the in-process database will always beat the network-attached one.

We measured it on the same MacBook Pro (M4) — same schema, same 50K operations, direct access (no HTTP): SQLite does 84.8K autocommit inserts/s and 561K point reads/s; Postgres 14.17 does 12K inserts/s and 29.8K reads/s (7× and 19× slower); MariaDB 12.0.2 does 11.9K inserts/s and 26.9K reads/s (7× and 21× slower). Even with synchronous_commit = off (Postgres’ version of the NORMAL tradeoff), writes stay 3× behind. See the full numbers.

Backup is copying a file

Postgres backup means pg_dump, or setting up replication, or configuring a managed service. MySQL is the same with mysqldump.

SQLite backup is cp app.sqlite backup.sqlite. For continuous replication, Litestream streams WAL frames to S3-compatible storage — zero downtime, zero app code changes, ~$0.01/month for a typical database. See the replication guide for the full setup.

What SQLite cannot do

This isn’t a one-sided argument. SQLite has real limitations:

Single writer — WAL allows concurrent readers, but only one writer at a time. busy_timeout handles contention, but if your app is write-heavy with high concurrency, Postgres handles this better.
No horizontal scaling — you can’t run multiple Dulak instances against the same SQLite file across different servers. Postgres/MySQL allow shared database access from multiple app instances.
No built-in replication — Litestream provides backup, not high availability. If the server dies, you restore to a new server and restart. There’s downtime. Postgres streaming replication gives you zero-downtime failover.
No fine-grained access control — SQLite has no users, roles, or row-level security. If you need multi-tenant access control at the database level, Postgres is the right tool.

When is the swap actually worth it?

The honest answer: when no single server can handle your traffic anymore. That’s a much higher bar than most people assume.

Dulak serves 52K reads/s on a single Bun process on a laptop. A production VPS with NVMe and more cores will do better. Even at 52K req/s, that’s 4.5 billion requests per day — and that’s the database-bound endpoint, not the health check. Most web apps consider 100K requests per day “high traffic.” You’d need to be serving hundreds of thousands of requests per second before SQLite’s single-writer constraint becomes the bottleneck, not the HTTP layer, not the app logic, not the network.

The real reasons to switch to Postgres are architectural, not performance:

You need multiple app servers — horizontal scaling means multiple processes writing to the same database. SQLite can’t do this; Postgres/MySQL can.
You need zero-downtime failover — Litestream gives you backup, not HA. If the server dies, there’s downtime during restore. Postgres streaming replication gives you instant failover.
You need row-level security or fine-grained access control — SQLite has no users, roles, or RLS.

Notice none of these are “SQLite is too slow.” They’re “my architecture outgrew single-server.” If you’re still on one server — even a busy one — SQLite is not your bottleneck.

And when that day comes, the swap is deliberate: replace bun:sqlite with a Postgres driver, update db.ts, adjust SQL syntax differences. No ORM means no abstraction layer to migrate through. Routes, auth, validation, SSR — none of it changes.

Why not start with Postgres then?

Because starting with Postgres means starting with infrastructure. Dulak’s philosophy is “your first week should be business logic, not infrastructure.” If you start with SQLite and never outgrow it — which most apps don’t — you’ve saved weeks of operational overhead for free. If you do outgrow it, the swap is a scheduled migration, not a fire drill.

Starting with Postgres “just in case” is the same logic as adding a cache service “just in case” — it’s solving a problem you don’t have yet, at the cost of complexity you pay for from day one.

Common SQLite myths

“SQLite is only for testing and prototypes”

SQLite is the most deployed database in the world — it runs in every Android device, every iOS device, every web browser (via WebSQL/WASM), every macOS installation, and countless production apps. It’s not a toy database; it’s a battle-tested engine that handles exabyte-scale workloads at Apple, Google, and Mozilla. The “prototype only” reputation comes from people who tried it with default settings and never tuned the PRAGMAs.

“SQLite can’t handle concurrent access”

WAL mode allows unlimited concurrent readers alongside one writer. Readers never block, and the writer never blocks readers. The only constraint is one writer at a time — and busy_timeout handles contention by waiting up to 5 seconds (configurable) before returning SQLITE_BUSY. For a web app where most requests are reads, this is a non-issue. Dulak serves 52K concurrent reads/s with zero lock contention.

“SQLite loses data on power failure”

With synchronous = FULL, SQLite is as durable as any database — every commit is fsync’d to disk before acknowledging. Dulak uses synchronous = NORMAL by default, which trades the last few WAL transactions for 27× write throughput. The database never corrupts — you might lose the last few milliseconds of writes on a power loss, but the file is always consistent. For financial records, switch to FULL. For a web app, NORMAL is the right tradeoff.

“SQLite doesn’t scale”

“Scale” means different things. SQLite scales to terabytes of data and billions of rows in a single file — the format handles it fine. What it doesn’t scale to is multiple servers writing simultaneously. If “scale” means “more servers,” you need Postgres. If “scale” means “more data on one server,” SQLite handles it.

“You’ll need to migrate to Postgres eventually”

Most apps never reach the point where SQLite is the bottleneck. The apps that do outgrow SQLite are the ones with specific needs: multi-server architecture, high-concurrency writes, or advanced replication. If you build a successful app that hits those limits, that’s a good problem to have — and the migration is a scheduled project, not an emergency. Starting with Postgres “just in case” means paying infrastructure tax from day one for a migration that probably never happens.

The short version

SQLite until no single server can handle your traffic — and that’s hundreds of thousands of requests per second, not hundreds.

The numbers: 526K reads/s and 95K writes/s direct on a laptop — 7–40× faster than Postgres and MariaDB on the same machine, measured the same way. The backup: copy a file. The swap: architectural, not performance — and scheduled, not emergency. The cost: zero infrastructure until you need it.

SSR vs SPA: 50ms to content, or 2 seconds of blank screen

Sat, 08 Aug 2026 00:00:00 GMT

SSR sends rendered HTML. SPA sends an empty div and a JavaScript bundle. That’s the difference, and it’s not theoretical — it’s 50ms vs 2 seconds on a budget phone, and it’s whether Google can read your page or queues it for a rendering pass that might take weeks.

The Inertia post covered the architecture: one router, one validator, no API layer. This post is about the rendering strategy — what the browser receives on the first byte, and why it matters.

What is SPA?

SPA (Single Page Application) is a rendering strategy where the server sends a bare HTML shell — typically just <div id="app"></div> and a <script> tag — and the browser downloads a JavaScript bundle, executes it, and renders the entire UI on the client.

The “single page” part means the browser loads one HTML document, then JavaScript takes over: routing, data fetching, rendering, and state management all happen in the browser. Navigating between pages doesn’t trigger a full page reload — JavaScript swaps content in and out of the DOM.

Examples: React apps built with Vite (no SSR), Vue apps with Vue Router, Angular apps. The server is a static file host or a JSON API — it never produces HTML with content in it.

What is SSR?

SSR (Server-Side Rendering) is a rendering strategy where the server produces full HTML — with content, headings, text, meta tags — on every request. The browser receives a complete document and can paint it immediately, before any JavaScript loads.

This is how the web worked before SPAs: PHP, Rails, Django, Express with a template engine — the server reads from the database, renders HTML, sends it. The browser displays it. JavaScript, if any, adds interactivity on top of the already-visible page.

Modern SSR (Next.js, Nuxt, SvelteKit, Dulak) adds a hydration step: after the HTML is visible, JavaScript loads in the background and “attaches” interactivity to the existing DOM — event listeners, state, client-side routing. The user sees content first, interactivity arrives second.

The difference in one sentence

SPA: the browser receives an empty shell, JavaScript renders everything. SSR: the server renders everything, the browser receives a complete page.

The rest of this post explains why that difference matters — for speed, for SEO, for mobile users, and for code complexity.

The blank screen problem

Here’s what a SPA sends on first load:

<div id="app"></div>
<script type="module" src="/assets/app-a1b2c3.js"></script>

That’s it. The user’s browser receives an empty <div> and a script tag. Nothing is visible until the browser downloads the JS bundle, parses it, executes it, and the framework mounts and renders. The timeline:

Server response — ~50ms (TLS + round trip + server processing)
JS download — 200KB bundle over 3G: ~800ms. Over 4G: ~200ms.
JS parse + compile — 200KB of JS on a budget phone: ~300–500ms. On a desktop: ~50ms.
Framework init + render — React mounts, runs effects, fetches data: ~200–500ms.

Total time to first contentful paint: 500ms on a fast desktop, 1.5–2 seconds on a budget phone over 3G. The user stares at a blank white screen the entire time.

Here’s what Dulak sends on first load (public route, SSR enabled):

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>Landing — Dulak</title>
  <link rel="stylesheet" href="/assets/app-a1b2c3.css" />
</head>
<body>
  <div id="app" data-server-rendered="true">
    <h1>Dulak</h1>
    <p>The deliberately boring full-stack boilerplate.</p>
    <!-- full rendered HTML here -->
  </div>
  <script type="module" src="/assets/app-a1b2c3.js"></script>
</body>
</html>

The HTML arrives with content in it. The browser parses HTML and paints it immediately — before the JS bundle even starts downloading. First contentful paint = server response time, ~50ms. The JS bundle loads in the background and Inertia takes over interactivity after the page is already visible.

The user sees content on the first byte. Not after JS downloads. Not after JS parses. Not after React mounts. On the first byte.

SEO and crawlability

Search engines crawl HTML. When Googlebot fetches a server-rendered page, it gets the full content in the HTTP response. The page is indexable on the first fetch — title, headings, text, links, meta tags, all present in the HTML.

When Googlebot fetches a SPA, it gets <div id="app"></div>. The content is behind JavaScript execution. Google can render JS — it uses a headless Chromium to execute the page’s scripts and index the resulting DOM. But this is a two-phase process:

First pass — Googlebot fetches the HTML, sees an empty div, queues the page for rendering.
Second pass — Google’s rendering queue (which has a backlog) executes the JS, renders the DOM, and indexes the content.

The second pass can be days or weeks later. And it’s less reliable — JS execution can fail, time out, or produce different output than expected. Google’s own documentation says: “Rendering JavaScript can be slow and we recommend server-side rendering or pre-rendering where possible.”

And Google is the best case. Other crawlers — Bing’s, social media bots (Twitter, Facebook, Slack, Discord), SEO auditors, accessibility tools — many of them don’t execute JavaScript at all. A SPA’s <div id="app"></div> is all they see. No Open Graph tags, no meta descriptions, no content. Your link preview is blank. Your page doesn’t exist to half the internet’s crawlers.

Dulak’s SSR sends full HTML with rendered content, <title> tags, and meta information on every public route. Every crawler sees the page. No rendering queue, no two-phase indexing, no “wait for the JS to execute.” The HTML is the content.

The mobile JS tax

JavaScript is the most expensive byte on the web. Here’s why:

HTML is parsed incrementally as it streams in. The browser can paint partial HTML before the full document loads.
CSS is parsed and matched against the DOM. Also relatively cheap.
JavaScript must be downloaded, parsed, compiled, and executed before it does anything. On mobile devices, this is 2–10× slower than on desktop.

A 200KB JS bundle (gzipped) is not 200KB of work. It’s 200KB of source that expands to 1MB+ of parsed code, which the browser must compile to native, execute, and garbage-collect. On a 2020-era budget Android phone with a slow CPU and limited memory, parsing 200KB of JS takes 300–500ms. On a 2018 phone, it can take over a second.

The SPA industry’s answer to this is the “JavaScript budget” — a constant battle to keep bundles small. Code-splitting, tree-shaking, lazy-loading route chunks, dynamic imports. You spend engineering time fighting bundle size because every KB of JS is a KB of delay on mobile.

SSR sidesteps the problem. The server renders HTML — the browser’s native, optimized format. The JS bundle still loads (Inertia needs it for interactivity), but it’s not on the critical path. The user sees content immediately. The JS loads in the background. If the JS takes 2 seconds to load on 3G, the user has been reading the page for 2 seconds already.

Dulak takes this further: SSR is skipped for authenticated routes. Behind a login wall, there’s no SEO benefit and no public crawler. The client hydrates and replaces server HTML anyway, so SSR is pure server CPU waste. Public pages get full SSR; authenticated pages ship an empty shell with the page payload inlined as JSON. Less server work, same UX.

// inertia.ts — the rendering decision
if (config.ssr && !this.c.user) {
  // Public route → full SSR HTML, content on first byte
  const rendered = await renderPage(page);
  return this.html(rendered.head, rendered.body, options.status ?? 200);
}
// Authenticated route → empty shell + JSON payload, client renders
return this.html([], this.clientBody(page), options.status ?? 200);

No hydration waterfall

Here’s what Next.js and Nuxt do:

Server renders HTML — React renders the component tree to HTML on the server.
HTML sent to client — user sees content (good).
JS bundle downloads — in the background.
Client hydrates — React re-renders the exact same component tree on the client, walks the DOM, attaches event listeners, and reconciles the server HTML with the client virtual DOM.

Step 4 is the hydration waterfall. The client does the same work the server just did — renders the same components with the same props — to attach interactivity. If the server and client render different output, you get a hydration mismatch warning and React throws away the server HTML and re-renders from scratch. You’ve paid for rendering twice and gotten nothing extra.

Dulak’s Inertia SSR is different. The server renders HTML with react-dom/server:

// ssr.tsx — runs inside the Hono process
export async function renderPage(page: Page) {
  return createInertiaApp({
    page,
    render: renderToString,
    resolve: (name) => pages[`./pages/${name}.tsx`]?.default ?? notFoundPage!,
    setup: ({ App, props }) => <App {...props} />,
    title: (title) => title ? `${title} — Dulak` : "Dulak",
  });
}

The client doesn’t re-render. When the JS loads, Inertia sees data-server-rendered="true" on the mount point and calls hydrateRoot instead of createRoot:

// app.tsx — client entry
setup({ el, App, props }) {
  const element = <App {...props} />;
  if (el.hasAttribute("data-server-rendered")) {
    hydrateRoot(el, element);  // attach, don't re-render
  } else {
    createRoot(el).render(element);  // fresh render (no SSR)
  }
}

hydrateRoot attaches event listeners to the existing DOM. It doesn’t throw away the server HTML and re-render. It doesn’t walk the tree and reconcile. It takes the DOM that’s already on screen and makes it interactive. The server did the rendering; the client does the wiring. One render, not two.

This is the key difference from Next.js/Nuxt SSR: those frameworks hydrate by re-rendering. Inertia hydrates by attaching. Less work, less CPU, less chance of mismatch.

In-process SSR, not a separate server

Next.js needs a Node.js server for SSR. Nuxt needs a Node.js server. SvelteKit needs a Node.js server. The SSR runtime is a separate process from your API, your database layer, your background jobs. You deploy two things (at minimum), manage two runtimes, and debug across process boundaries.

Dulak renders SSR in the same Bun process as the HTTP server and the database. The renderPage function in src/client/ssr.tsx runs inside the Hono request handler. The Inertia adapter calls it directly:

// inertia.ts — render() method, inside the HTTP handler
async render(component, props, options) {
  const page = this.page(component, props);
  if (this.isXhr) {
    return this.json(page, options.status ?? 200);  // Inertia XHR → JSON
  }
  if (config.ssr && !this.c.user) {
    const rendered = await renderPage(page);  // SSR, same process
    return this.html(rendered.head, rendered.body, options.status ?? 200);
  }
  return this.html([], this.clientBody(page), options.status ?? 200);  // empty shell
}

No second runtime. No inter-process communication. No separate deployment. No SSR server to scale independently. The HTTP server, the database (bun:sqlite), and the SSR renderer all share one event loop, one process, one deployment.

This works because Bun runs react-dom/server natively. There’s no need for a separate Node process — Bun handles the React SSR render in-process, on the same event loop that handles HTTP requests and database queries. The render takes single-digit milliseconds for a typical page. No bottleneck, no separate infrastructure to manage.

The middleware wires it all together per request:

// inertia-middleware.ts — one adapter per request, same process
export const inertiaMiddleware = (assets) => async (c, next) => {
  const sessionToken = getCookie(c, SESSION_COOKIE);
  const user = resolveUser(sessionToken);
  c.set("inertia", new Inertia({ request: c.req.raw, headers: ..., user, flash }, assets));
  await next();
};

One process. One middleware. One adapter per request. The route handler calls c.var.inertia.render(...) and gets back a Response — HTML for browser visits, JSON for Inertia XHR. See the request lifecycle for the full flow.

The 2026 angle: less code for AI to break

Here’s where this gets interesting. In 2026, a growing share of code is AI-generated. The cost of producing code is approaching zero. The cost of maintaining code is not.

A SPA architecture requires AI to generate and maintain:

Client-side routing logic (route definitions, guards, lazy loading, code splitting)
State management (stores, reducers, selectors, cache invalidation)
An API layer (endpoints, serialization, pagination, error handling)
Hydration logic (server/client reconciliation, mismatch handling)
Data fetching (loading states, error states, refetching, optimistic updates)

Each of these is code that AI must generate correctly, and then maintain correctly when requirements change. Each is a surface where AI can introduce bugs — a route guard that doesn’t match the server, a state shape that drifts from the API contract, a hydration mismatch that only appears in production.

SSR is simpler code. The server renders HTML from database state. The client displays it. There’s less to generate, less to maintain, less to break. When code is free to produce, the rational choice is the architecture that produces less code — not because the code is expensive to write, but because it’s expensive to keep correct.

Dulak’s entire client-side rendering logic is 27 lines. The SSR entry point is 22 lines. The rendering decision in the adapter is 4 lines. That’s the full rendering strategy — server renders HTML, client attaches interactivity. An AI maintaining this codebase has very few surfaces to get wrong.

The SPA complexity isn’t there because it’s necessary — it’s there because the architecture demands it. Choose a different architecture and the complexity doesn’t exist. You can’t break code that was never written.

When a SPA rendering strategy makes sense

SSR isn’t universally better. SPAs are the right rendering choice when:

The app is already a SPA — if you’ve built Figma or Google Maps, the client is the application. SSR adds nothing because the content is generated by user interaction, not by the server.
You’re on the edge — Cloudflare Workers, Vercel Edge Functions. No long-lived process means no in-process SSR. You’d need a separate SSR server, which defeats the point.
Content is fully dynamic and client-generated — a collaborative whiteboard, a real-time trading dashboard. The server can’t pre-render what doesn’t exist until the user interacts.

Dulak is for server-rendered web apps — dashboards, admin panels, SaaS products, content sites. Apps where the server knows the state and can render it to HTML. If your app’s content exists before the user interacts, SSR is the right rendering strategy.

The short version

Ship HTML, not a div.

A SPA sends <div id="app"></div> and a JS bundle. The user waits. A crawler waits (or gives up). A budget phone chokes on the JS parse. Dulak sends rendered HTML on the first byte — content visible immediately, crawlers see everything, mobile users aren’t paying the JS tax.

And unlike Next.js/Nuxt, there’s no hydration waterfall — Inertia attaches interactivity to existing DOM, it doesn’t re-render. No separate SSR server — it runs in the same Bun process as your HTTP server and database. No second deployment, no inter-process communication, no hydration mismatch debugging.

The Inertia post explains why you don’t need a client-side router, an API layer, or Redux. This post explains why the user sees content faster, Google can read your page, and budget phones don’t choke. Same architecture, different argument. See the request lifecycle for how it all fits together in one process.

Tailwind is a build step you don't need

Sat, 08 Aug 2026 00:00:00 GMT

Let’s get this out of the way first: Dulak offers Tailwind templates. You can run bun create dulak@latest my-app --template react-tailwind and get React 19 + Tailwind CSS v4 with the same auth, SSR, and test suite. Same for Svelte and Vue. This is not a post about why Tailwind is bad. It’s a post about why vanilla CSS is the default — and why that default is a deliberate choice, not a lazy one.

Tailwind adds a build dependency

Tailwind is a utility-class framework that generates CSS at build time. It’s powerful — you compose styles inline without touching a separate file, and the compiler purges unused classes so the output stays small. But “generates CSS at build time” means you need a build step.

For Dulak’s Tailwind templates, that means adding two dependencies (tailwindcss + @tailwindcss/cli), a tailwind.css input file, a dev:css watch script, and a pre-build step in your asset pipeline. The build time goes from 0.2s to 0.4s. The dev server restart adds ~350ms. None of these are catastrophic — but they’re all costs you pay from day one for a feature you may not need.

Vanilla CSS has none of this. No PostCSS config, no purge config, no content scanning, no CLI step. The CSS you write is the CSS that ships. Bun.build bundles all imported .css files into one stylesheet via the import graph — same as it bundles your .tsx files. Zero extra tooling.

Co-located CSS, not a global soup

The strongest argument against vanilla CSS is the old experience: one giant styles.css file, 2000 lines, nobody knows what’s still used, specificity wars, !important everywhere. That was the CSS of 2012. Dulak doesn’t do that.

Dulak’s pattern is co-located CSS. Each component imports its own .css file. styles.css holds only global base — design tokens, reset, and shared UI primitives. Everything else lives next to the component that uses it:

src/client/
  styles.css           # tokens, reset, .btn, .badge, .panel, .table, .avatar
  components/
    Brand.css          # .brand, .brand-mark
    Field.css          # .field, .field-hint, .field-error
    Layout.css
    AuthLayout.css
  pages/
    Dashboard.css      # .stats, .stat-card, .stat-value
    Admin.css
    Profile.css

Here’s what Dashboard.css actually looks like:

/* Dashboard: stat cards. */

.stats {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(180px, 1fr));
  gap: 1rem;
  margin: 1.5rem 0;
}

.stat-card {
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: 1.25rem;
}

That’s it. No utility classes, no @apply, no config. You read it, you understand it, you move on. The design tokens (--surface, --border, --radius) come from styles.css, where they’re defined once for light and dark themes:

:root,
[data-theme="light"] {
  --bg: #f6f7fb;
  --surface: #ffffff;
  --border: #e4e7ef;
  --primary: #059669;
  --radius: 12px;
}

[data-theme="dark"] {
  --bg: #0f1117;
  --surface: #171a23;
  --border: #2d3444;
  --primary: #10b981;
}

Dark mode is a [data-theme] attribute on <html>. No framework, no plugin, no dark: prefix. The tokens cascade. Every component that uses var(--surface) gets the right value automatically.

The “CSS is hard” myth

CSS was hard in 2015. Browser inconsistencies were real — flexbox had vendor prefixes, grid didn’t exist, calc() was flaky, and IE9 was still a thing you had to support. Frameworks like Bootstrap and Tailwind emerged to paper over those inconsistencies. They gave you a consistent API on top of an inconsistent platform.

It’s 2026. The platform caught up:

CSS Grid — grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)) gives you a responsive card layout in one line. No grid-cols-4 breakpoint juggling.
Custom properties — var(--primary) is a design token. Change it in one place, it updates everywhere. No @apply or theme config needed.
Native nesting — CSS now supports & .child nesting natively in all modern browsers. No Sass required.
:focus-visible — accessible focus styles without a plugin.
color-mix() — blend colors at runtime without a preprocessor.

The problems Tailwind solved — browser inconsistencies, lack of a grid system, no design tokens — are mostly gone. What’s left is the utility-class API itself, which is a preference, not a solution.

And in 2026, there’s a deeper reason to prefer vanilla CSS: code is AI-generated. Tailwind’s other pitch was developer speed — p-4 text-center is faster to type than writing a .card class and a CSS rule. But when AI generates your CSS, that friction is gone. The AI writes vanilla CSS just as easily as it writes Tailwind classes. The “faster to write” argument was a human-friction argument, and human friction is no longer the bottleneck. What matters now is what ships: vanilla CSS is zero-dependency, zero-build-step, and readable by anyone. Tailwind ships a build dependency and a translation layer. When code is free to produce, you optimize for what runs, not what’s easy to type.

Readability cuts both ways

Tailwind’s pitch is that you don’t context-switch between HTML and CSS. Everything is in one place. That’s true — and for small components, it’s genuinely nice.

Here’s the same stat card in Tailwind:

<div className="grid grid-cols-[repeat(auto-fit,minmax(180px,1fr))] gap-4 my-6">
  <div className="bg-white dark:bg-surface border border-gray-200 rounded-xl p-5">
    <span className="text-xl font-bold">42</span>
  </div>
</div>

And here it is in Dulak’s vanilla CSS:

<div className="stats">
  <div className="stat-card">
    <span className="stat-value">42</span>
  </div>
</div>

The Tailwind version is longer, the class names are denser, and the responsive grid syntax is grid-cols-[repeat(auto-fit,minmax(180px,1fr))] — which is the CSS syntax wrapped in brackets. You’re writing CSS anyway, just through an abstraction layer.

The vanilla version has a .stats class that maps to a 4-line CSS rule in Dashboard.css. Anyone who knows CSS can read it. Anyone who knows Tailwind has to learn the utility API first — gap-4 means gap: 1rem, rounded-xl means border-radius: 0.75rem, my-6 means margin: 1.5rem 0. It’s a translation layer between you and the CSS you’re already writing.

When Tailwind makes sense

This is where the nuance matters. Dulak ships Tailwind templates because Tailwind has real advantages in specific situations:

Large teams — a utility-class system enforces consistency. You can’t accidentally invent a new shade of blue when the palette is fixed. For 10+ developers, that constraint is worth the abstraction tax.
Rapid prototyping — when you’re iterating on a design and don’t want to name things yet, utility classes are faster. p-4 text-center font-bold is quicker than writing a .card-title class and a CSS file.
Designers who think in utilities — some teams have internalized the Tailwind mental model and are genuinely faster with it. That’s a valid preference.

Dulak’s Tailwind templates use Tailwind v4 via @tailwindcss/cli — no PostCSS required. The existing CSS variables bridge cleanly to Tailwind’s theme tokens, and dark mode auto-switches via [data-theme]. The same auth, roles, SSR, and test suite work across both vanilla and Tailwind templates. It’s a preference, not a religion.

The philosophy angle

Dulak’s philosophy is “zero-dependency where cheap” and “no abstraction tax.” Vanilla CSS is zero-dependency. The build step is zero-config. The CSS you write is the CSS that ships. Co-located CSS gives you the same locality benefit Tailwind sells — styles live next to the component — without the utility-class translation layer.

The decision was locked on August 3, 2026, and the reasoning was simple: the boilerplate’s UI is small and already built. Tailwind’s speed advantage (composing utilities inline) pays off in projects you fork into, not in the boilerplate you fork from. Shipping vanilla CSS by default means one less opinion to undo if you disagree with it — and if you want Tailwind, you don’t migrate: you scaffold the Tailwind template from day one. --template react-tailwind is the same auth, SSR, and test suite with Tailwind already wired. There is no migration path because there’s nothing to migrate — the choice is made at bun create, not after.

The default should be the thing that’s easiest to change your mind about — and with the template flag, changing your mind means scaffolding again, not rewriting stylesheets. Vanilla CSS wins that test.

The short version

Vanilla CSS by default. Tailwind when you want it.

The default is zero-dependency, zero-build-step, readable by anyone who knows CSS. If you prefer Tailwind, you don’t migrate — you pick bun create dulak@latest my-app --template react-tailwind from day one and get the same app with Tailwind already wired. The choice is made at scaffold time, not after. Pick the default that’s cheapest to change — and with the template flag, both are one command away. See the installation guide for all available templates.

Your 2GB upload keeps failing. Here's the fix

Sat, 08 Aug 2026 00:00:00 GMT

A 2GB video upload over a plain multipart form will fail. Not maybe — it will fail, usually at 90%, and the user starts over. The reasons are structural: a dropped connection kills the whole request, proxies cap body sizes, and one long request can time out.

The fix is chunking: split the file, upload piece by piece, track progress, resume where you left off. The tus protocol does exactly this, and Bun has a spec-compliant implementation you can use as-is.

This tutorial walks through the whole thing — server, client, resume, progress — on Dulak.

Step 1: server — tus endpoints

Dulak ships tus at /uploads out of the box: creation, resume (HEAD), chunked append (PATCH), termination, checksums. Auth and ownership are enforced on every endpoint. There is nothing to install — it’s three flat modules, zero dependencies.

# already enabled — nothing to configure
curl -X OPTIONS http://localhost:4000/uploads

The server returns tus capabilities. Uploads land in UPLOAD_DIR (default ./data/uploads), with one SQLite row per upload tracking offset, length, and owner.

If you’re not on Dulak: any tus server works — tus-node-server, tusd, or a cloud variant. The client code below is protocol-standard and works against any of them.

Step 2: client — a zero-dependency upload

Dulak’s client doesn’t use a tus library — the protocol is simple enough to drive with plain fetch, and the profile avatar upload does exactly that. Zero dependencies, consistent with the “no abstraction tax” philosophy.

The pattern has three moves: create (POST), resume (HEAD), append (PATCH in a loop):

const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB per request

/** tus `Upload-Metadata` values are standard base64. */
function toBase64(s: string): string {
  const bytes = new TextEncoder().encode(s);
  let bin = "";
  for (const b of bytes) bin += String.fromCharCode(b);
  return btoa(bin);
}

async function createUpload(file: File): Promise<string> {
  const res = await fetch("/uploads", {
    method: "POST",
    headers: {
      "Tus-Resumable": "1.0.0",
      "Upload-Length": String(file.size),
      "Upload-Metadata": `filename ${toBase64(file.name)},filetype ${toBase64(file.type)}`,
    },
  });
  if (!res.ok) throw new Error(`Create failed (HTTP ${res.status})`);
  const location = res.headers.get("Location");
  if (!location) throw new Error("Server did not return an upload URL");
  return location.split("/").pop() ?? ""; // the upload id
}

async function getOffset(uploadId: string): Promise<number> {
  const res = await fetch(`/uploads/${uploadId}`, {
    method: "HEAD",
    headers: { "Tus-Resumable": "1.0.0" },
  });
  if (!res.ok) return 0;
  return Number(res.headers.get("Upload-Offset")) || 0;
}

async function runUpload(file: File) {
  const uploadId = await createUpload(file);
  let offset = await getOffset(uploadId); // 0 on a fresh upload

  const bytes = new Uint8Array(await file.arrayBuffer());
  while (offset < bytes.byteLength) {
    const end = Math.min(offset + CHUNK_SIZE, bytes.byteLength);
    const res = await fetch(`/uploads/${uploadId}`, {
      method: "PATCH",
      headers: {
        "Tus-Resumable": "1.0.0",
        "Content-Type": "application/offset+octet-stream",
        "Upload-Offset": String(offset),
      },
      body: bytes.slice(offset, end),
    });
    if (!res.ok) throw new Error(`Chunk failed (HTTP ${res.status})`);
    offset = end;
    console.log(`Uploaded ${Math.round((offset / bytes.byteLength) * 100)}%`);
  }
  return uploadId;
}

That’s the whole upload: create once, then PATCH chunks until the offset reaches the file length. Each PATCH is a small, proxy-safe request.

Why 5MB chunks?

Two constraints meet here:

Proxy limits. Cloudflare caps request bodies at 100MB — a single request over that is rejected at the edge. Chunks must stay well under it.
Failure cost. A dropped connection re-sends only the in-flight chunk. 5MB is small enough that the retry is cheap, large enough that HTTP overhead per chunk stays negligible.

Anything from 1MB to 10MB works; 5MB is a sane default. (Dulak’s avatar upload uses 256KB chunks — fine for small files, too many requests for a 1GB one.)

Step 3: resume after interruption

This is the whole point of tus. When the connection drops, the upload doesn’t die — it stops, and you can continue. Two pieces make that work:

1. Remember the pending upload. On creation, save the upload id — on the next page load, the UI offers “Resume upload” instead of starting over:

const PENDING_KEY = "dulak:avatar:upload";
type PendingUpload = { id: string; name: string; size: number };

// after createUpload() returns the id:
localStorage.setItem(PENDING_KEY, JSON.stringify({ id: uploadId, name: file.name, size: file.size }));

2. Resume from the saved id. getOffset() re-reads the server’s Upload-Offset, and the PATCH loop continues from there:

async function runUpload(uploadId: string, file: File) {
  let offset = await getOffset(uploadId); // server says where we stopped
  const bytes = new Uint8Array(await file.arrayBuffer());
  while (offset < bytes.byteLength) {
    // ... PATCH loop, same as Step 2
  }
}

// On file re-selection, if it matches the pending upload:
const pending = JSON.parse(localStorage.getItem(PENDING_KEY) ?? "null");
if (pending && pending.name === file.name) {
  await runUpload(pending.id, file); // resume — no restart
} else {
  const id = await createUpload(file);
  localStorage.setItem(PENDING_KEY, JSON.stringify({ id, name: file.name, size: file.size }));
  await runUpload(id, file);
}

The server is the source of truth for the offset — the client never guesses. A dropped connection at 90% means re-sending only the last 5MB chunk, not the whole file.

Step 4: progress that survives reloads

The progress bar is easy; making it survive a refresh is the useful part. The offset comes from the server, so the bar snaps to the true position on resume:

// inside the PATCH loop:
setProgress(Math.round((offset / bytes.byteLength) * 100));

// on resume, getOffset() returns the real progress before the loop starts

Because the server tracks Upload-Offset in SQLite, a page reload doesn’t lose the position — the HEAD request in getOffset() restores it. Clear PENDING_KEY when the upload completes and link the file (Dulak POSTs the upload id to /profile/avatar).

Step 5: verify with network throttling

Test the resume path before shipping — it’s the part that’s easy to get wrong:

Open DevTools → Network → throttling, pick “Slow 3G”
Start uploading a 200MB file
Kill the connection mid-upload (toggle to Offline)
Re-enable the network, resume
Confirm the upload continues from where it stopped, not from zero

If it restarts, the server offset and the client’s saved URL don’t match — check that uploadUrl is being persisted and passed back correctly.

When you don’t need any of this

If your files are under ~100MB and the connection is reliable, a plain multipart form is simpler and correct:

const form = await c.req.formData();
const file = form.get("file");
await Bun.write(`${config.upload.dir}/${file.name}`, file);

Ten lines, no client library, no protocol. The form data guide covers it. Use tus only when the file is big enough that a failed upload costs real time — that’s the ~100MB line.

The short version

Small files: form data. Files over ~100MB: tus.

Server: shipped in Dulak at /uploads — nothing to install. Client: three fetch calls — POST to create, HEAD to get the offset, PATCH in a loop — zero dependencies, exactly what Dulak’s own avatar upload does. Resume: save the upload id, re-read the offset via HEAD. Progress: bytesSent / bytesTotal from the PATCH loop. Test with network throttling before you trust it. The tus docs have the full protocol and configuration reference.

Your database is already the cache

Sat, 08 Aug 2026 00:00:00 GMT

Every time someone evaluates Dulak, the same question comes up: “Where’s the cache layer?”

The answer is: you’re looking at it. It’s the database.

SQLite is already fast enough

bun:sqlite with WAL mode serves 526,000 reads per second and 95,000 writes per second direct — the raw engine numbers, measured on a MacBook Pro (M4). Through the full HTTP stack — auth, sessions, and request routing included — that’s still 52,000 reads per second and 19,600 creates per second. The database is not the bottleneck at any layer.

For comparison, a typical Redis deployment over the network adds 0.5–1ms of latency per round trip. SQLite reads from a local file with WAL cache — no network hop, no serialization, no connection pool. The database is the cache.

Prepared statements are already cached

Dulak creates all prepared statements once at module load in db.ts:

const stmts = {
  getUserById: db.query("SELECT * FROM users WHERE id = ?"),
  getSession: db.query("SELECT * FROM sessions WHERE token = ?"),
  // ...
};

These are reused for every request. The query plan is compiled once and cached in memory. This is the same caching layer that an ORM provides — except it’s zero-dependency and you can see the exact SQL.

Cache invalidation is a business-logic problem

A generic cache service doesn’t know what to cache. It doesn’t know which queries are expensive, which results change frequently, and which can be safely stale. Only your business logic knows that.

A cache that caches the wrong thing is worse than no cache at all. It serves stale data, causes confusing bugs, and adds a debugging layer between your code and your database. Dulak’s philosophy is “no abstraction tax” — a cache service you haven’t needed yet is exactly that tax.

When you actually need a cache

Dulak doesn’t ship a cache because most apps don’t need one at launch. But there are legitimate cases:

Read-heavy workloads with expensive queries — complex joins or aggregations that can’t be optimized further. An in-memory LRU for specific query results makes sense.
Outgrowing SQLite — if you move to Postgres with a connection pool, Redis for session storage or query caching may help.
External API rate limits — caching third-party API responses to avoid hitting rate limits.

These are all post-launch decisions. You build, you ship, you measure, and then you add a cache where the data tells you to. Not before.

The real question

The real question isn’t “why no cache service?” It’s: what problem would it solve that SQLite doesn’t already solve?

If your answer is “I might need it someday” — that’s not a problem. That’s a maybe. Dulak ships solutions to real problems, not maybes.

Your SPA needs a router, an API, and state. Inertia needs none of it

Sat, 08 Aug 2026 00:00:00 GMT

Every time someone evaluates Dulak, the same question comes up: “Where’s the client-side router? Where’s the API layer? Where’s Redux?”

The answer is: you don’t need them. And you probably never did.

What a SPA actually costs

A Single Page Application is not “a fast website.” It’s an architecture, and that architecture has a price. Here’s what you build when you commit to a SPA:

A client-side router — React Router, TanStack Router, Vue Router. You define routes on the client and on the server. Two routing systems, two sources of truth, two things that can disagree.
An API layer — REST endpoints or GraphQL resolvers. The server stops rendering HTML and becomes a JSON factory. You design the API, version it, document it, and consume it.
Client-side state management — Redux, Zustand, Pinia. The client fetches data from the API, stores it, caches it, invalidates it, and synchronizes it. This is an entire application running in the browser.
Client-side validation — you validate on the client for UX, then validate again on the server because you can’t trust the client. Two validation systems, two sets of rules, two things that drift.
A server that’s just an API — no rendering, no templating, no HTML. Just JSON in, JSON out.

That’s two codebases. Client routing and server routing. Client validation and server validation. Client state and server state. You’re maintaining two applications that talk to each other over a wire protocol you invented.

Inertia is not a SPA

Inertia gives you the thing you actually want from a SPA — no full page reloads — without the architecture you don’t. Here’s how Dulak uses it:

The server decides what page to show. The server decides what data to pass. The client receives a page payload and renders it. That’s it.

// pages.routes.ts — the server decides everything
app.get("/dashboard", requireAuth, (c) =>
  c.var.inertia.render("Dashboard", { stats: dashboardStats() }),
);

One line. The server checks auth, queries the database, builds the props, and tells Inertia to render the Dashboard component with those props. No API endpoint to design. No fetch call to write. No state to manage. The route handler is the controller and the data layer.

When the user navigates, Inertia makes an XHR request with the X-Inertia header. The server responds with a JSON page payload instead of full HTML. Inertia swaps the component on the client. No page reload, no flicker, no white screen. The user experience is indistinguishable from a SPA.

When the user does a hard refresh or lands from an external link, the server renders full HTML with SSR and the client hydrates. Same route, same handler, same code path — the adapter handles the difference.

No client-side router

Dulak’s client entry point is 27 lines:

app.tsx

createInertiaApp({
  id: "app",
  resolve,
  setup({ el, App, props }) {
    const element = <App {...props} />;
    if (el.hasAttribute("data-server-rendered")) {
      hydrateRoot(el, element);
    } else {
      createRoot(el).render(element);
    }
  },
  title: (title) => title ? `${title} — Dulak` : "Dulak",
});

There is no router here. No route definitions, no route guards, no lazy-loaded route chunks, no <Outlet> components. The page registry is a plain object mapping component names to modules — that’s it:

export const pages: Record<string, PageModule> = {
  "./pages/Dashboard.tsx": { default: Dashboard },
  "./pages/Login.tsx": { default: Login },
  // ...
};

Routing lives on the server, where it belongs. The server already knows the URL, the session, the user’s role, and the database state. Why duplicate that logic on the client? In Dulak, a route guard is a server-side middleware:

app.get("/admin", requireRole("admin"), (c) =>
  c.var.inertia.render("Admin", { users }),
);

If you’re not an admin, you never get the page. No client-side redirect, no flash of unauthorized content, no route guard to keep in sync with the server. The server is the source of truth.

No API layer

In a SPA, the server exposes endpoints and the client consumes them. You design the contract, serialize the data, handle pagination, deal with loading states and error states.

In Dulak, the server passes props directly to the page component. The Dashboard component receives stats as a prop — the same way a server-rendered template receives variables. No useEffect, no fetch, no useState for loading:

export default function Dashboard({ stats }: { stats: DashboardStats }) {
  // stats is just here. No fetching, no loading state.
  return <div>{stats.userCount} users</div>
}

For form submissions, Inertia’s useForm helper handles the POST and the response. The server validates, processes, and redirects. The client doesn’t need to know the API shape — there is no API:

const { data, setData, post, processing, errors } = useForm({
  email: '',
  password: '',
});

const submit = (e: FormEvent) => {
  e.preventDefault();
  post('/login');  // that's a route, not an API endpoint
};

post('/login') hits the same Hono route that serves the login page. No API contract to maintain.

Validation in one place

In a SPA, you validate on the client (for instant feedback) and on the server (because you can’t trust the client). Two schemas, two rule sets, two things that drift out of sync.

Dulak validates once — on the server, with TypeBox:

const registerBody = t.Object(
  {
    name: t.String({ minLength: 2, maxLength: 80 }),
    email: t.String({ format: "email" }),
    password: t.String({ minLength: 8, maxLength: 72 }),
  },
  { additionalProperties: false },
);

When validation fails, the server returns a 422 with field errors in the Inertia page payload. The client displays them via errors from useForm:

<Field id="email" label="Email" error={errors.email}>

One schema. One validation pass. One set of error messages. The client doesn’t validate — it just displays what the server says. If you change a rule (password minimum from 8 to 12), you change it in one file. Not two.

SSR is in-process, not a separate server

Most SSR setups run a separate Node process for server-side rendering. You deploy your API server, your SSR server, and your static assets. Three things to manage, three things that can disagree on versions.

Dulak renders React on the server in the same Bun process that handles HTTP:

// ssr.tsx — runs inside the Hono process
export async function renderPage(page: Page) {
  return createInertiaApp({
    page,
    render: renderToString,
    resolve: (name) => pages[`./pages/${name}.tsx`]?.default ?? notFoundPage!,
    setup: ({ App, props }) => <App {...props} />,
    title: (title) => title ? `${title} — Dulak` : "Dulak",
  });
}

The render() method in the Inertia adapter decides what to do based on the request:

async render(component, props, options) {
  const page = this.page(component, props);
  if (this.isXhr) {
    // Inertia client request → JSON payload
    return this.json(page, options.status ?? 200);
  }
  if (config.ssr && !this.c.user) {
    // Browser visit, public route → full SSR HTML
    const rendered = await renderPage(page);
    return this.html(rendered.head, rendered.body, options.status ?? 200);
  }
  // Authenticated route → empty shell + JSON, client renders from scratch
  return this.html([], this.clientBody(page), options.status ?? 200);
}

No separate SSR server. No hydration mismatch debugging across processes. One process, one deployment, one thing to manage. And Dulak skips SSR for authenticated routes — no SEO benefit behind a login wall, and the client hydrates and replaces server HTML anyway. Public pages get full SSR for crawlers; authenticated pages ship an empty shell. Less server CPU, same UX.

The mental model: server-driven UI

Here’s the shift in thinking: Inertia is server-driven UI. The server is the application. The client is a template engine.

In a SPA, the client is the application. It fetches data, manages state, handles routing, and renders. The server is a data API.

In Dulak, the server is the application. It handles routing, auth, validation, database queries, and decides what page to render with what data. The client receives a component name and props, and renders them. That’s the client’s entire job.

This is why Dulak doesn’t need Redux, Zustand, React Router, or an API layer. Those tools solve problems that Inertia’s architecture doesn’t create.

When a SPA actually makes sense

This isn’t a one-sided argument. SPAs are the right choice for certain apps:

Rich interactive apps — Figma, Google Maps, video editors. These apps have complex client-side state (canvas, drag-and-drop, real-time collaboration) that doesn’t map to page transitions. The client is the application.
Edge-deployed apps — if you’re running on Cloudflare Workers or Vercel Edge, you might not have a long-lived server process. A SPA with an API backend fits that model.
Offline-first apps — if your app needs to work without a network connection, you need client-side state, client-side storage, and client-side sync logic. Inertia doesn’t help here.

Dulak is for server-rendered web apps — dashboards, admin panels, SaaS products, content sites. Apps where the server is the source of truth and pages are rendered from database state. If you’re building Figma, you’re in the wrong place.

The short version

Inertia until you need a canvas.

The SPA architecture exists to solve specific problems: rich client-side interaction, edge deployment, offline support. If you don’t have those problems, you’re paying the SPA tax — two routers, two validators, an API layer, and a state management library — for a navigation feel you get for free with Inertia.

Dulak ships one router (server), one validator (server, TypeBox), one state source (server, props), and SSR in the same process. The client renders what the server tells it to render. See the request lifecycle for the full flow.