Skip to main content

27 posts tagged with "v3"

View All Tags

From fmt.Println to Production Logging in Fiber v3

ยท 7 min read
Fiber Team
Maintainers

There is a moment in every project's life where someone greps the production logs for a bug report and realizes that fmt.Println("got here") is the only evidence of what happened. The request came in, something went wrong, and the logs show a status code with no context about which user, which endpoint, or which upstream service was involved.

Logging sounds boring until it is 2 AM and your only debugging tool is kubectl logs. At that point, the difference between a flat text line and a structured JSON object with a request ID, latency, and user context is the difference between finding the bug in five minutes and finding it in two hours.

Fiber v3's Logger middleware is designed to bridge that gap without requiring you to rewrite your application.

Testing Fiber Apps: The Patterns Nobody Talks About

ยท 6 min read
Fiber Team
Maintainers

Every Fiber tutorial shows you how to test a single GET handler. Create an app, register a route, call app.Test(), check the status code. Done.

Then you try to test something real - a middleware chain where auth runs before validation, a custom error handler that renders different responses based on content type, a route group with shared state - and the tutorial patterns fall apart. The handler works in isolation but fails when composed. The test passes with a hardcoded body but breaks when you add a request ID middleware that changes the response shape.

Testing Fiber applications well requires patterns that match how Fiber applications actually work: as compositions of handlers, middleware, and configuration that interact in specific ways.

Rate Limiting: Protecting Your API Without Punishing Your Users

ยท 6 min read
Fiber Team
Maintainers

Rate limiting is one of those features that every production API needs, nobody enjoys implementing, and most teams get subtly wrong the first time.

The common mistake is not forgetting rate limiting entirely. It is applying a single global limit and calling it done. Fifty requests per minute, no exceptions, no differentiation. Your power users hit the wall during normal operations. Scrapers figure out the exact limit and stay just below it. Login endpoints get the same allowance as read-only data endpoints. Everyone is equally unhappy.

Fiber v3's Limiter middleware ships with the primitives to do better: dynamic limits per route, sliding window algorithms, per-user keys, and pluggable storage backends. The trick is knowing when to use which.