33 posts tagged with "go"

Picture a bug report that is really a cost problem. A summary endpoint calls a slow upstream, an LLM API in our case, and users who get bored close the tab after a second or two. The frontend is fine with that. The invoice is not: the upstream bill shows complete generations for requests whose clients were long gone. The handler passed its context to the upstream client, so everybody assumed that a closed connection would cancel the call. It never did.

If you came to Fiber from net/http, Gin, Echo or Chi, that assumption is reasonable. In those frameworks, the request context is canceled when the client disconnects. Fiber runs on fasthttp, and fasthttp does not watch the connection while your handler runs. The fiber.Ctx you get satisfies context.Context, so the code compiles, but it is a context that can never be canceled. It is one of the most frequently reported surprises in the issue tracker (see #4335 or #4263), and the method docs in v3.5.0 now state it in plain words.

This post shows what you can rely on instead, with one service that we build and test against Fiber v3.5.0: a deadline for request/response handlers, disconnect detection for streams, and a clean way to end long streams when the server shuts down.

Search endpoints have a way of outgrowing their URLs. The filters start small, ?category=shoes&max_price=150, and then product asks for multi-select categories, tag combinations and price ranges, maybe a saved filter that a dashboard sends verbatim. Eventually the query string is an encoded JSON blob that nobody can read in the access log, and someone moves the endpoint to POST /search.

POST works, but it describes the request wrongly. It tells every layer between client and server that the request might change state. Shared caches practically never store POST responses, clients and proxies should not replay it on their own after a dropped connection, and your CSRF middleware demands a token for what is really a read. The IETF has now published RFC 10008, which defines a dedicated QUERY method: safe and idempotent like GET, but with a request body. Fiber has supported it as a first-class verb since v3.4.0, released in July.

This post builds a product search on QUERY with Fiber v3.5.0, caches it properly, and walks through the places where the new method interacts with middleware you already run. Two of them can serve one user's results to another if you are not careful.

Fiber's API was inspired by Express, and it shows: routes look the same, parameters use the same :name syntax, middleware chains work the way you expect. If you know Express, you already know most of Fiber - you just do not know the spelling yet.

This post is the phrasebook. Express on the left, Fiber v3 on the right, organized by what you do all day: read requests, write responses, chain middleware, handle errors. At the end, the three differences that are not spelling - the ones that cause real bugs when Node instincts meet Go.