Learning Fiber - Core Concepts & Main Architecture

#Introduction

Episode 1 covered why Fiber exists. Episode 2 now breaks down core concepts and main architecture — how Fiber works behind the scenes. You don't need to memorize code in this episode; the main goal is building a correct mental model.

This mental model matters because it determines how you solve problems later: why values in c.Params are only valid inside a handler, why allocations must be minimized, and why hooks can handle application lifecycle. All those questions come from the architecture we're about to dissect.

#The Request Flow Behind the Scenes

#From Socket to Handler

When a request comes in, the path it travels is very short. Fasthttp accepts the connection, creates a fasthttp.RequestCtx, then hands it to the handler produced by fiber.App via app.Handler(). That's where Fiber's router works: matching path and method to a chain of handlers.

client → fasthttp server → fiber.App → router stack → middleware → handler → response
                                 ↓
                    fiber.Ctx membungkus fasthttp.RequestCtx

An important consequence: fiber.Ctx is not an expensive new allocation per request. Fiber takes it from a pool, refills it, and returns it to the pool after the request finishes. This is the source of Fiber's speed.

#Reused Buffers

Because fasthttp buffers are reused, strings and bytes obtained from a request are only valid while the handler runs. If you store c.Params("id") into a global variable, its value can be changed by another request. To keep data across requests, you must copy it — a pattern we use again in episodes 12 and 19.

#Fiber's Core Components

#App, Router, and Ctx

• App: the fiber.App instance that stores config, router, and hooks. Created with fiber.New().
• Router: the data structure that maps methods and paths to lists of handlers, including groups, mounts, and domains.
• Ctx: the fiber.Ctx interface that wraps fasthttp.RequestCtx and provides request, response, cookie, and locals helpers.
• Handler: the func(fiber.Ctx) error function that is the smallest unit of execution in Fiber.

#Middleware, Hooks, Binding, and Error Handler

• Middleware: a handler invoked before the target handler, registered via app.Use.
• Hooks: callbacks at lifecycle moments, such as when listening starts or before shutdown.
• Binding and Extractors: v3 mechanisms to map body, query, header, and URI to structs, and to extract values with fallbacks.
• Default Error Handler: the built-in error handler that converts an error into an HTTP response.

#fiber.Ctx: The Heart of Every Handler

#The Bridge to Fasthttp

All request and response interactions happen through fiber.Ctx. Behind the scenes, it holds a pointer to fasthttp.RequestCtx accessible via c.RequestCtx(). Some of the most frequently used methods:

func handler(c fiber.Ctx) error {
    name := c.Params("name")
    age := c.Query("age", "0")
    body := c.Body()
    c.Locals("request_id", "abc-123")
 
    return c.JSON(fiber.Map{
        "name": name,
        "age":  age,
        "body": string(body),
    })
}

c.Params("name") retrieves the path parameter value, c.Query("age", "0") reads a query parameter with a default, and c.Body() returns the body as bytes. All these values are guaranteed to be valid only while the handler runs because they come from reused buffers.

#Inspecting the Route Structure

To verify how the router stores routes, Fiber provides app.Stack():

routes, err := json.MarshalIndent(app.Stack(), "", "  ")
if err != nil {
    log.Fatal(err)
}
log.Println(string(routes))

app.Stack() returns a slice per HTTP method, each containing paths and parameter names. Understanding this output helps a lot when debugging route conflicts in episode 19.

#Minimal Allocation and Zero-Copy

#Design Principle

Fiber follows the principle of minimal allocation: avoid creating new objects per request as much as possible. Binding structs are reused, fasthttp buffers are managed with sync.Pool, and strings are not copied unless necessary. The results show up in go test -benchmem — a topic we'll explore in episode 17.

go test -bench=. -benchmem -benchtime=1s

The B/op and allocs/op columns show the bytes and number of allocations per operation. go test -bench=. -benchmem -benchtime=1s will be our main weapon when measuring performance in episodes 17 and 19.

#Practical Consequences

Because of the zero-copy principle, there's a rule to remember: if you want to keep a request value for use after the handler finishes, use c.App().GetString(...) or strings.Clone. Fiber provides the GetString and GetBytes helpers specifically for this case when Immutable is enabled. We'll cover the details when we discuss context and concurrency.

#Closing

Key takeaways:

• fiber.App is built on fasthttp, not net/http.
• fiber.Ctx wraps fasthttp.RequestCtx and is only valid inside a handler.
• Core components: App, Router, Ctx, Handler, Middleware, Hooks, Binding, and the default error handler.
• Fasthttp buffers are reused, so request data must be copied if you want to keep it.
• app.Stack() helps you inspect the route structure; go test -benchmem measures allocations.

In the next episode, episode 3, we build setup and your first hello world — installing Fiber v3, creating an App instance, adding the default Logger and Recover middleware, then returning JSON and text responses with the correct status codes. Time for your first code.