Webhook signature verification (timing-safe compare)

For webhooks, I assume the internet is hostile by default. I don’t trust that a request ‘looks like’ it came from Stripe/GitHub/etc; I verify the signature over the raw request body and use crypto.timingSafeEqual to avoid leaking information via timin

Idempotency keys for “create” endpoints

Retries are inevitable: mobile clients, flaky networks, and load balancers will resend POST requests. Without idempotency you end up double-charging or double-creating records. I store an Idempotency-Key with a sha256 hash of the request body and the

Postgres connection pooling with pg + max lifetime

After getting burned by long-lived connections that slowly accumulate bad state (or get killed by the network) and then explode during peak traffic, I got strict about pg pooling. I keep the pool size small per instance and scale horizontally instead

Graceful shutdown for Node HTTP servers

Deploys got a lot calmer once I treated SIGTERM as a first-class signal instead of an afterthought. In Kubernetes (and most PaaS platforms), you’re expected to stop accepting new requests quickly while finishing in-flight work. The worst failure mode

Runtime validation for request bodies (Zod)

TypeScript only protects you at compile time; your API still receives untrusted JSON from the internet. I lean on Zod as the source of truth for parsing + validation so runtime and types stay aligned. The big win is that I don’t try to validate ‘every

Request ID + structured logging (Express + pino)

Debugging distributed requests is miserable without a stable request id, so I generate it once at the edge, echo it back via x-request-id, and attach it to every log line with a child logger. I keep this intentionally boring because it delivers 80% of

Turbo Frames: conditional frame navigation for mobile vs desktop

Sometimes you want frame navigation on desktop but full-page navigation on mobile. You can decide the target frame at render time. This keeps UX tuned without duplicating controller actions.

Stimulus: bulk selection + Turbo batch action

For batch operations, Stimulus can manage the UI state (select all, indeterminate checkbox) while Turbo submits a regular form. This keeps the server in charge of authorization and the UI simple.

Turbo Streams: partial replace with morphing (less jitter)

When replacing DOM chunks, morphing reduces flicker and preserves focus/selection. If you enable morphing, prefer server-rendered HTML that’s stable and keyed. It’s a subtle but meaningful quality improvement.

Stimulus: autosave draft with Turbo-friendly requests

Autosave drafts without fighting Turbo: send a fetch request with CSRF token, keep it separate from the main form submit, and surface “Saved” status unobtrusively. This is a great fit for content editors.

Turbo Streams: append server-side validation warnings

Sometimes you want to show non-blocking warnings (e.g., “link looks unreachable”) while still saving. Turbo streams can append warnings to a panel without rerendering the whole page.

Stimulus: resilient confirmation for destructive actions

Turbo supports data-turbo-confirm, but sometimes you want a stronger confirmation step (type-to-confirm, extra context, multi-step). Stimulus lets you implement consistent confirmations without sprinkling JS across views.