32 posts tagged with "v3"

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.

For a lot of applications - admin panels, dashboards, internal tools, CRUD frontends - the default stack of a JavaScript SPA talking to a JSON API is more machinery than the problem needs. Two codebases, a bundler, a node toolchain in CI, and client-side state that mirrors what the server already knows.

HTMX takes the opposite approach: the server renders HTML, and a small script extends HTML with attributes like hx-get and hx-target so any element can fetch a fragment and swap it into the page. No build step, no client-side router, no JSON serialization layer.

Fiber is a natural fit for this. Its template engines render fragments fast, the whole application compiles to one binary, and the request handling you already know - routing, binding, middleware - is all there is to learn. Let's build a live-search contact list to see the full loop.