$ cd ./topics/backend
API design, services and data, messaging and migrations, Node.js and the JVM: the server side of the systems I build, and where I'm growing next.
19 notes🌱 4 seed🌿 12 growing🌳 3 evergreen
Most of my career has been on the front end, but the interesting problems keep sitting on the boundary: API shapes, streaming data, migrations, gateways and the services behind them. These notes collect what I’ve learned on the server side, and they’re where I’m deliberately growing next.
hover to explore · click to open
Case study: a Node.js tool I built at Elanco in 2020 to move whole sites from Contentful to Kentico Kontent: export to disk, a work queue, batched streaming, adapter layers and resumable runs. It became open-source tooling and a guest post on Kontent's blog.
Case study — putting a declarative API gateway in front of a platform's microservices with little dedicated ops support. Versioned routes, stable names, one place for CORS, and validating locally before asking for anything.
Put a layer between external APIs and your UI that parses raw responses into your own domain models, so a backend change touches one adapter instead of forty components.
At-most-once, at-least-once and "exactly-once". Why the network forces you to choose between losing messages and duplicating them, and how idempotency makes duplicates harmless.
A persistent, two-way channel between browser and server. Brilliant when both sides talk often; the price is stateful connections you now have to scale, heartbeat and reconnect.
The server's side of real-time sync: what a snapshot must carry, what a delta must say, how sequence numbers and resync work, and why edits should share the snapshot's shape.
An honest plan, not a claim of expertise: what I already bring to back-end work after years leading front ends (API contracts, real-time protocols, migrations, gateways, observability), and what I'm deliberately learning next.
Floating-point rounding, hard-coded currencies and duplicated pricing logic in the UI: why price conversion and money calculations belong behind an API, with base and term currencies explicit and a decimal library wherever numbers are money.
Three API questions that came up on a real-time trading platform: should a bulk delete be a DELETE with a body, should one big GET become several small ones, and who cancels a request nobody needs any more?
Keeping a live screen correct under streaming updates: subscribe and buffer first, load a snapshot, apply only newer deltas by sequence number, and never let an incoming update overwrite what the user is editing.
My 2021 explainer on Spring covered beans, inversion of control and n-tier layers. A 2026 refresh from someone working alongside Java services: what still matters, what Spring Boot made default, and what I'm learning next.
Why Node is fast until you block it, how streams make backpressure explicit, and how I used the same ideas in a CMS migration tool and in real-time UIs. Grounded in two books and one tool I actually built.
In 2020 I swung between a headless CMS I could edit from my phone and plain Markdown files. Since then I've migrated whole sites between CMSs and rebuilt this site on Markdown fed from my notes. The answer depends on who writes, how often, and from where.
A container orchestration platform whose core idea is reconciliation: you declare the state you want, and control loops keep nudging the cluster towards it.
Patterns for moving large amounts of data between systems without running out of memory or starting over: extract to a staging area, queue the work, stream in batches, adapt between models, and checkpoint everything.
A reactive TypeScript backend where your server functions are the API, so front end and back end stay in sync. A natural fit for building with coding agents.
One-way server-to-client streaming over plain HTTP, with automatic reconnection built into the browser. The simplest right answer for feeds, progress updates and streaming AI responses.
Program vs process vs thread, and the three "multis" (multiprogramming, multiprocessing, multithreading): the units every concurrency discussion is built from.
A coordinator asks every participant to prepare, then tells them all to commit or abort. It gives atomic distributed transactions, but blocks if the coordinator fails at the wrong moment.