Backend & API Development

Most backend work is not a blank slate. It is designing an API and a data model that other things already depend on, or that will have to sit next to a system that already exists and cannot stop running while it changes. I design for that directly: typed contracts from the database to the API to the UI, clear ownership of each piece of data, and validation at every boundary that takes input from outside the service.

On PostgreSQL I use Prisma where it fits; on MongoDB I model around how the application actually reads data rather than forcing a relational shape onto it. Where a queue is the right tool — RabbitMQ for a telemetry pipeline, SQS for background jobs — I use one, so a slow consumer or a burst of traffic does not take down the request path.

A recurring version of this problem is modernising in place: improving the API surface of a legacy platform and building new interfaces beside it, instead of a rewrite that stops the business while it happens. That is how the service CRM and the master-data platform in my work are both structured.