2 posts tagged with "postgres"

Every Fiber middleware that needs to persist data - sessions, rate limiter counters, cache entries, CSRF tokens - uses the same Storage interface. That means you can swap from in-memory storage to Redis to Postgres to DynamoDB by changing one line of configuration. Your middleware code stays exactly the same.

Most developers discover this the hard way: they build with the default in-memory storage, deploy to production, and realize their rate limiter resets on every restart and their sessions vanish during rolling deployments. The fix is not a rewrite - it is a one-line storage swap.

CRUD APIs are often where a backend project either becomes maintainable or becomes expensive.

At first, everything feels easy: a quick route, a quick DB call, done. Three months later, handlers parse requests in different ways, errors are inconsistent, and every change takes twice as long as expected.

This post is about avoiding that path from the start.

We'll use Fiber v3 with the gorm-postgres recipe, but the real goal is not just to "get CRUD working." The goal is to set up a structure your team can still understand when the API grows.