#backend

data models, APIs, and a bot that watches a blockchain

0pedev1:05 PM

I started on the front end, and it's still where I'm fastest. But the problems I keep choosing lately are behind the interface: what the schema should be, what happens when two requests hit the same row, and what a service should do when the data it needs isn't there yet.

Two projects taught me most of it — one a database exercise dressed up as a fan site, the other a bot that watches Base for new tokens and has to be right about money.

2 attachments

Canary2026

A Telegram bot that scores every new Base token for rug risk.

TypeScriptTelegrafviem

Aang vs Korra — 1000 Reasons2026

1,000 rows, a Prisma schema, and the API to page through them.

PrismaPostgreSQLNext.js

→ web work the stack

Aang vs Korra — 1000 Reasons

2026 · Prisma · PostgreSQL · Next.js · TypeScript · Zod

The project where I actually learned the data layer. The front end is a thin shell over the part that mattered: a Prisma schema with migrations and a seed script that loads 1,000 ranked records, then REST endpoints that page, filter, search and tally votes against Postgres.

What it does

Two Prisma models with a real migration history and a seed script for the 1,000 rows.

Pagination, category filter and text search resolved in the query — skip/take with a composed where clause, not filtered in the browser.

findMany and count run in parallel so a page and its total cost one round trip.

Page and limit are clamped server-side, so a hand-edited query string can't ask for the whole table.

Votes increment atomically via upsert, which sidesteps the read-modify-write race entirely.

Driver adapters let the same schema run on Postgres in production and SQLite locally.