Service worker: cache static assets safely

Offline-first is hard, but caching static assets is an easy win for repeat visits. I keep the service worker scope narrow and cache only versioned assets (hashed filenames) so I don’t accidentally serve stale HTML or API responses. The most common fai

Web Vitals reporting to an API endpoint

Synthetic performance tests don’t always match what real users experience. Web Vitals reporting gives you field data (CLS, LCP, INP, etc.). I collect vitals on the client and POST them to a lightweight endpoint, then aggregate on the backend. Sampling

Next.js middleware for auth gating

Protecting routes at the middleware layer prevents a whole class of ‘oops, we forgot to check auth on one page’ bugs. middleware.ts runs before rendering, so unauthenticated users get redirected early and you don’t waste work. I keep the logic simple:

React Hook Form + Zod resolver

Forms are where type safety and UX collide. react-hook-form keeps re-renders low, and Zod gives me a single schema I can share between frontend and backend if I want. I wire zodResolver so field-level errors show up automatically, and I keep a stable

MSW for frontend API mocking in tests

Brittle test suites often come from mocking fetch at every call site. MSW lets me mock at the network layer: components make real HTTP calls, but the test environment intercepts them and returns deterministic responses. That keeps tests closer to real

Email sending with nodemailer + templates

Email is still a core product channel, and it’s easy to ship broken messages if you don’t treat it like code. I keep templates in source control, render them with a simple templating engine, and send via nodemailer (or a provider SDK). I always includ

Cron scheduling with node-cron (with guard)

Periodic jobs are common (cleanup, digests, rollups), and it’s easy to accidentally run them on every instance in production. In local dev, in-process node-cron is fine. In production, I either run a dedicated worker or add a guard so only one instanc

BullMQ job idempotency via dedupe id

Retries are great, but duplicates are inevitable—workers crash, Redis reconnects, deploys happen. I prefer building idempotency into the job key itself. BullMQ supports a jobId that acts like a de-dupe key: if a job with the same id already exists, en

Partial index for “active” rows in Postgres

Not all queries benefit from a full-table index, especially when most rows are ‘inactive’ or archived. A partial index lets you index only the subset you care about (like active users or un-deleted records), which shrinks index size and improves cache

Postgres advisory lock for one-at-a-time work

Sometimes you just need ‘only one worker does this thing at a time’, and building distributed locks from scratch is risky. Postgres advisory locks are a pragmatic option when your DB is already the source of truth. I derive a deterministic lock key (l

Password reset tokens: hash + expiry

Reset flows are a common place to accidentally store secrets in the database. I generate a random token, email it to the user, and store only a hash in the DB alongside an expiry timestamp. When the user redeems the token, I hash what they provide and

JWT access + refresh token rotation (conceptual)

A single long-lived JWT is a liability: if it leaks, it’s valid until it expires and revocation is hard. I use short-lived access tokens and longer-lived refresh tokens, and I rotate refresh tokens on every use. Rotation means that if an attacker stea