31 posts tagged with "go"

Fiber's core ships with 20+ middleware - logger, CORS, rate limiter, sessions, and more. But some middleware needs external dependencies: JWT requires a token library, OpenTelemetry needs the OTel SDK, WebSockets depend on a WebSocket implementation. Instead of bloating Fiber's core with these dependencies, they live in a separate repository: gofiber/contrib.

The contrib packages are first-party middleware. Same team, same quality, same release cycle. The only difference is that they have external Go dependencies, so they are imported separately to keep your go.sum clean when you do not need them.

Not every project is a JSON API. Sometimes you need to render HTML - a landing page, an admin panel, an email template, a server-rendered app. Fiber supports 9 template engines through a single Views interface, so you pick the syntax you like and Fiber handles the rest.

The surprising part is not the number of engines. It is that switching from one engine to another requires changing exactly two lines of code: the import and the engine constructor. Your handlers, layouts, and rendering calls stay the same.

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.