Convex

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the reactive backend I actually need instead of Convex — and be honest about the verdict.

What you are paying for is **automatic invalidation**: the platform knows which queries a write affects and re-runs exactly those. Reproducing that properly means tracking read dependencies per query execution and matching them against writes, which is real work. The pragmatic version — declare what each query depends on — gets ninety per cent of the benefit for a tenth of the effort, and that is what this builds.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode. One writer, serialised, which makes the whole model simpler
- Server-sent events for pushing to clients: one connection, no protocol to implement, and it reconnects itself
- Caddy in front

THE SHAPE
- Queries and mutations are functions on the server, not SQL in the client. The client calls them by name with arguments
- A mutation runs in a single transaction. If it throws, nothing happened — that is the transactional guarantee, and SQLite gives it to you for free
- A query is pure and read-only, and can therefore be re-run and cached safely
- Every function declares the tables and, where possible, the keys it reads. That declaration is what makes invalidation possible

INVALIDATION
- After a mutation commits, collect the tables and row keys it wrote
- Match them against the declared dependencies of every live subscription, and re-run only those queries
- Re-run, compare the result to what the client last received, and push only if it changed. That last check removes most of the traffic
- The pragmatic middle ground: declare dependencies at the table level to start, and narrow to keys for the queries that turn out to be hot. Table-level invalidation over-fires, and over-firing is far safer than missing
- Write down the rule: if a function reads something it did not declare, the client will silently go stale. Make the declaration part of the function's definition so it cannot be forgotten, and add a development-mode check that compares the declared set to what was actually read

SUBSCRIPTIONS
- The client subscribes to a query with arguments; the server keeps the arguments, the declared dependencies and the last result hash
- One event stream per client, multiplexing every subscription
- On reconnect the client re-subscribes and gets current results immediately, so a dropped connection is invisible
- Authorisation checked at subscription time and again on every re-run, so a permission change takes effect at once

SCHEDULING AND JOBS
- A queue table with a lease, retries with backoff, and idempotency keys
- Scheduled functions with a cron expression and a time zone
- A mutation can schedule work to run after it commits, which is the correct place for side effects — sending an email inside a transaction that later rolls back is the classic bug this avoids

THE REST OF THE BACKEND
- Schema as migrations applied once, in order, from files
- Authentication with sessions as long random tokens stored hashed, argon2id for passwords, rate limits on every auth route
- File storage on disk by hash, served through a permission check
- Every function is ordinary code in your repository, deployed by your deploy. No separate platform

THE HONEST LIMIT
- One process and one SQLite file means one machine. That is fine for a very large number of applications, and it does not scale sideways
- Write down what you would do next — read replicas, or a client-server database with the same schema — so the simple choice is deliberate rather than accidental

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; nightly backup with continuous replication, and a tested restore
- Health endpoint reporting live subscriptions and queue depth

WHAT MATTERS MOST
Dependency declaration and the development-mode check that catches a missing one. An under-declared dependency means a client that quietly shows stale data, which is the worst failure mode this design has.