2 posts tagged with "production"

Every Go tutorial ends the same way: log.Fatal(app.Listen(":3000")). The server starts, the tutorial is done. Nobody talks about what happens when the server stops.

Here is what happens: a deploy rolls out, the process gets SIGTERM, and every request that was mid-flight - a database write, a file upload, a payment confirmation - gets killed instantly. The client sees a connection reset. The database row is half-written. The payment went through but the confirmation never reached the user.

Graceful shutdown is not a nice-to-have. It is the difference between "the deploy went fine" and "we lost three transactions during the rollout."

The scariest thing in production is not that errors happen. It is that the wrong information leaks when they do.

In Fiber v3, the default error handler sends err.Error() to the client, which can expose a raw database error, an internal file path, or other library-generated details. Panics are a separate concern: Fiber does not recover them by default, so they crash the process unless you enable the Recover middleware. During development, that kind of visibility is helpful. In production, it is a security incident waiting to happen. An attacker learns your ORM, your table schema, maybe even the specific query that failed. All from a 500 response you never thought anyone would read.

Fiber v3's error handling is designed around one idea: handlers return errors, and a central handler decides what the client sees. That separation sounds simple, but it changes how you structure error responses across your entire application.