You've written a few scripts in Go. Now you need to build an API. You open the standard library and see http.HandleFunc. It works, but you're tired of writing JSON marshaling by hand. You check GitHub and find a dozen frameworks promising speed, middleware, and magic. Gin, Echo, Chi, Fiber. They all look similar. They all have stars. They all claim to be the best. The choice feels heavy because the wrong pick can lock you into a style that fights the language for years.
Frameworks are wrappers, not replacements
Go web frameworks are wrappers around the standard library's net/http package. The standard library gives you a router, a request/response cycle, and a server. Frameworks add convenience: automatic JSON binding, middleware chains, and context helpers.
Think of net/http as a raw engine block. Chi is a lightweight chassis bolted directly to it. Echo and Gin are full cars with radios and cup holders. Fiber is a completely different engine designed for drag racing. It's faster in a straight line, but it doesn't fit in a standard garage.
Most frameworks use net/http under the hood. They register a handler with http.ListenAndServe and add their own routing logic on top. This means you can swap frameworks without breaking your deployment pipeline. Fiber is the exception. It uses fasthttp, a third-party server that bypasses net/http entirely. Fiber trades compatibility for raw throughput.
Minimal example: Echo
Echo strikes a balance between convenience and standard compliance. It uses net/http, supports middleware, and provides a clean API for common tasks.
package main
import (
"net/http"
"github.com/labstack/echo/v4"
"github.com/labstack/echo/v4/middleware"
)
// Main starts the Echo server with logging and recovery.
func main() {
// Echo.New initializes the framework instance.
e := echo.New()
// Middleware runs before the handler. Logger prints request details.
e.Use(middleware.Logger())
// Recover catches panics and returns a 500 error instead of crashing.
e.Use(middleware.Recover())
// GET registers a route. The handler gets a Context object.
e.GET("/users/:id", func(c echo.Context) error {
// Param extracts the route variable safely.
id := c.Param("id")
// JSON sends a response with the correct content-type header.
return c.JSON(http.StatusOK, map[string]string{"id": id})
})
// Start listens on the port and blocks until the process exits.
e.Start(":1323")
}
Echo gives you structure without hiding the engine.
How the request flows
When you call e.Start, Echo wraps your router in a standard http.Server. The server accepts TCP connections and hands them to the router. The router matches the URL path using a radix tree. If the path matches, the middleware stack runs.
Each middleware wraps the next handler. The logger writes to stdout, then calls the next middleware. The recover middleware wraps the handler in a defer to catch panics, then calls the handler. Your function runs. You call c.JSON, which marshals the map to bytes, sets the Content-Type header, and writes to the response. The connection closes or stays alive for keep-alive.
This flow is identical to net/http. Echo just hides the boilerplate. You don't write json.Marshal or w.Header().Set. You call c.JSON. The framework does the work.
Middleware is a chain. Break the chain and the request fails.
Realistic example: Context and errors
Production code needs error handling and cancellation. Go uses context.Context to manage request lifecycles. The context carries deadlines, cancellation signals, and request-scoped values.
package main
import (
"context"
"fmt"
"net/http"
"time"
"github.com/labstack/echo/v4"
)
// GetUser retrieves a user by ID with a timeout.
func GetUser(c echo.Context) error {
// Context carries the request lifecycle and cancellation signal.
ctx := c.Request().Context()
// WithTimeout creates a context that cancels after 500ms.
// This prevents slow database queries from holding connections.
reqCtx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
defer cancel()
// Param extracts the ID from the URL.
id := c.Param("id")
// fetchUser simulates a database call that respects cancellation.
user, err := fetchUser(reqCtx, id)
if err != nil {
// fmt.Errorf wraps the error with context for debugging.
return fmt.Errorf("get user %s: %w", id, err)
}
return c.JSON(http.StatusOK, user)
}
// fetchUser simulates a data fetch.
func fetchUser(ctx context.Context, id string) (map[string]string, error) {
// In real code, pass ctx to the database driver.
// The driver will abort the query if ctx is cancelled.
select {
case <-ctx.Done():
// ctx.Err() returns context.Canceled or context.DeadlineExceeded.
return nil, ctx.Err()
case <-time.After(100 * time.Millisecond):
return map[string]string{"id": id, "name": "Alice"}, nil
}
}
Functions that accept a context must take it as the first parameter, named ctx. This is a universal convention. If you write a helper that talks to a database, sign it as func fetch(ctx context.Context, id string). The defer cancel() call is mandatory for WithTimeout and WithCancel to prevent resource leaks.
Context is plumbing. Run it through every long-lived call site.
Pitfalls and runtime traps
Every framework has trade-offs. Fiber's speed comes from memory reuse. Gin's convenience comes from reflection. Chi's minimalism comes from boilerplate.
Fiber uses fasthttp, which reuses memory buffers to avoid allocations. The fasthttp server allocates a large buffer once and reuses it for every request. This eliminates garbage collection pressure. It also means data is temporary. The string returned by c.Params("id") points to that buffer. If you store the string in a variable and the handler returns, the buffer gets overwritten by the next request. Your stored string turns into garbage. You must copy the data. Use strings.Clone or string() to create a safe copy. This is the most common Fiber bug. Developers store a param, spawn a goroutine, and get corrupted data.
Fiber's speed comes from reusing memory. Copy data before you store it.
Gin offers c.Bind(&user). This reads the request body and populates the struct using reflection. It checks JSON tags. It's convenient. It's also slower. Reflection requires the runtime to inspect types at runtime. It adds latency. For high-throughput services, manual unmarshaling is faster. Also, binding hides errors. If the JSON is malformed, Bind returns an error. If you ignore it, you get a zero-value struct. Always check the error. if err := c.Bind(&user); err != nil { return err }.
If you pass a pointer to a pointer to Bind, Gin panics with reflect: call of reflect.Value.Interface on zero Value. Always pass a pointer to the struct, not the struct itself.
Gin binds data, but reflection hides bugs.
Chi is a router. It does not handle JSON encoding or logging. You must compose your own server using net/http. If you forget w.Header().Set("Content-Type", "application/json"), the client gets raw bytes. The browser might render text instead of parsing JSON. There's no compiler error here. It's a runtime logic bug.
Chi also forces you to drop the error return pattern. Handlers return nothing. You write directly to http.ResponseWriter. This feels un-Go-like to some developers. Go functions return errors. Chi handlers swallow them. You have to check errors manually and write status codes.
The compiler rejects Fiber middleware written for net/http with cannot use middleware (type func(http.Handler) http.Handler) as type fiber.Handler. You have to find Fiber-specific middleware or write adapters. This limits your ecosystem.
Chi is a router, not a framework. Build the rest yourself.
Decision: which framework fits your project
Use Echo when you want a complete framework that stays compatible with net/http and offers a mature middleware ecosystem. Use Fiber when you have profiled your service and confirmed that request throughput is the bottleneck, and you are willing to sacrifice standard library compatibility for raw speed. Use Gin when your team already knows its API and you value its reflection-based binding convenience over strict type safety. Use Chi when you only need a router and want to compose your own server with standard library primitives. Use net/http directly when your service is simple and you prefer zero dependencies.
Pick the tool that matches your constraints. Performance is a feature, not a goal.