Field Guides Tagged as "Backend"

Databases, auth, jobs and queues, and server-side foundations.

Mastering Directus

Directus has quietly become the first thing I reach for on almost every project, and not just as a headless CMS. Point it at a Postgres database and you get an instant REST and GraphQL API, a genuinely nice admin app your non-technical teammates can actually use, granular permissions, file handling, automation, and realtime, without writing a line of boilerplate. I rarely start an app these days without standing up Directus at some point. This is the guide I'd hand a competent developer who's never run Directus in anger: how to self-host it properly with Docker and Railway, how to model your data, how to lock it down, and how to ship real apps on top of it. _This is a living document and will be updated as Directus updates_

Read guide

Postgres for App Developers

Not DBA theory, the 20% of Postgres that carries 80% of real apps: schema design, indexing, transactions, the query patterns that matter, and the gotchas that bite in production.

Read guide

Auth, Done Right

Sessions, cookies, password hashing, and the subtle things people get wrong, a practical, build-along guide to authentication that's secure by default, without reaching for a SaaS.

Read guide

Background Jobs & Queues

The part of every real app nobody teaches well: workers, queues, retries, idempotency, scheduling, and dead-letter handling, built up from first principles into a system you can trust.

Read guide

MCP from Scratch

Every AI tool you've wired up by hand (the Slack integration, the database lookup, the "let the model read our docs" hack) is a one-off. You wrote the glue, you own the glue, and the next model or the next client can't use any of it. The Model Context Protocol is the fix: one open standard for how an AI app talks to your tools, your data, and your prompts, so you build the integration once and every MCP-aware client (Claude Code, Claude Desktop, Cursor, and a growing list) can use it. This is the guide I'd hand a competent developer who keeps hearing "MCP" and wants to actually build one instead of nodding along. We start from the problem it solves, get the mental model straight (hosts, clients, servers, and the three things a server exposes (tools, resources, prompts)) then build a real server from an empty folder: a tool the model can call, a resource it can read, a prompt it can reuse. We test it with the Inspector, wire it into Claude and Cursor, then take it remote over Streamable HTTP and talk honestly about the security boundary you're now responsible for. By the end you'll understand exactly what's happening when a model "uses a tool," and you'll have shipped a server you can point any MCP client at. _This is a living document and will be updated as the protocol and SDKs evolve._

Read guide