Chapter 26

Web Services and Router Design

In 2014, Gin framework author Manu Martinez-Almeida published the first version on GitHub. His motivation was simple: the standard library's net/http was too verbose, and existing frameworks were too slow. He wrote in the README: "Gin uses a custom version of HttpRouter, which is 40 times faster than Martini."

This single sentence shook the Go web framework ecosystem.

But where did that 40x performance gap come from? Martini was a typical reflection-driven framework — it used reflection at runtime to parse function signatures and inject dependencies. Reflection is slow; everyone knows that. Gin chose a different path: static types, zero allocation, and radix tree routing. Understanding the engineering logic behind these choices is the real goal of this chapter.

Level 1 · What You Need to Know

HTTP/1.1 vs HTTP/2 in Go

Before we discuss routing, we need to understand how Go's HTTP server actually works.

HTTP/1.1 is a text-based protocol. Each request occupies one TCP connection (Keep-Alive reuses connections, but a single connection handles only one request at a time). Browsers often maintain 6 TCP connections per domain to achieve concurrent resource loading.

Go's standard library net/http spawns one goroutine per connection:

// Simplified version of what net/http does internally
func (srv *Server) Serve(l net.Listener) error {
    for {
        rw, err := l.Accept()
        if err != nil { ... }
        c := srv.newConn(rw)
        go c.serve(connContext) // one goroutine per connection
    }
}

This design is natural in Go: goroutine creation costs only 2KB of stack memory, and context switching is far cheaper than OS threads. Go can comfortably handle tens of thousands of concurrent connections.

HTTP/2 brings multiplexing. A single TCP connection can simultaneously handle multiple request streams, with requests and responses split into frames that interleave. This eliminates the HOL (Head-of-Line Blocking) problem of HTTP/1.1.

Go's standard library has built-in HTTP/2 support since version 1.6:

package main

import (
    "log"
    "net/http"
    "golang.org/x/net/http2"
    "golang.org/x/net/http2/h2c"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        // Check protocol version
        if r.ProtoMajor == 2 {
            w.Write([]byte("Hello from HTTP/2!"))
        } else {
            w.Write([]byte("Hello from HTTP/1.1"))
        }
    })

    // HTTPS automatically negotiates HTTP/2 via ALPN
    // h2c is HTTP/2 Cleartext, for non-TLS scenarios (local dev / internal networks)
    h2s := &http2.Server{}
    handler := h2c.NewHandler(mux, h2s)
    
    log.Fatal(http.ListenAndServe(":8080", handler))
}

For HTTPS (production), Go automatically negotiates HTTP/2 through TLS ALPN with no extra configuration:

// This is all you need — ListenAndServeTLS enables HTTP/2 automatically
log.Fatal(http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil))

Why isn't HTTP/2 always better? For internal service-to-service communication (microservices), HTTP/1.1 with Keep-Alive may be sufficient, while HTTP/2's frame parsing adds overhead. HTTP/2 truly shines when serving browsers many small assets (CSS/JS/images), or when Server Push is needed.

Why Gin Is Popular: Zero-Allocation Middleware Chain

Gin's popularity is rooted in predictable performance. At C10K or C100K scale, allocating extra memory per request multiplies GC pressure, causing service latency spikes (GC pauses).

Gin's zero-allocation design manifests in three ways:

*gin.Context object pool (sync.Pool): After each request completes, the Context object is returned to the pool and reused by the next request.
Radix tree routing: Route matching produces no dynamic memory allocations; it operates directly on tree nodes.
Middleware chain is a slice: HandlersChain is essentially []HandlerFunc, built at route registration time. At request time, handlers are simply executed by index — no linked-list node creation.

// Gin middleware chain memory model (conceptual)
At route registration:
handlers = [Logger, Auth, RateLimiter, BusinessHandler]
             [0]     [1]      [2]            [3]

At request time:
c.index = -1  →  c.Next()  →  index=0 executes Logger
                               Logger calls c.Next()  →  index=1 executes Auth
                                                          Auth calls c.Next()  →  index=2 ...

This design keeps middleware chain execution entirely on the stack, with no heap allocations that the GC would need to track.

Level 2 · How It Works

Gin's Routing Tree: The Radix Tree

A naïve routing table uses a hash map: map[string]Handler. For exact matches this is fast, but it cannot handle path parameters (/users/:id) or wildcards (/static/*filepath).

Gin uses httprouter under the hood, which implements a radix tree (also called a compressed prefix tree). A radix tree is a compressed version of a Trie — if a node has only one child, they are merged.

Consider these routes:

GET /users
GET /users/:id
GET /users/:id/posts
GET /about

The corresponding radix tree structure:

/ (root)
├── users (node)
│   └── / (node)
│       └── :id (param node)
│           └── /posts (node)
└── about (node)

Route matching algorithm (simplified):

// httprouter core matching logic (conceptual simplification)
func (n *node) getValue(path string, params *Params) (handle HandleFunc) {
    walk:
    for {
        prefix := n.path
        if len(path) > len(prefix) {
            if path[:len(prefix)] == prefix {
                path = path[len(prefix):]  // consume matched prefix
                
                if n.wildChild {  // has parameter child
                    n = n.children[len(n.children)-1]
                    switch n.nType {
                    case param:
                        // found ':' param, consume until next '/'
                        end := 0
                        for end < len(path) && path[end] != '/' {
                            end++
                        }
                        *params = append(*params, Param{
                            Key:   n.path[1:],  // strip ':' prefix
                            Value: path[:end],
                        })
                        path = path[end:]
                        continue walk
                    }
                }
                // exact-match child node
                // uses path[0] as index for fast lookup
                ...
            }
        }
        ...
    }
}

Why is a radix tree better than a hash map for routing?

A hash map must store the complete path string as a key. For /api/v1/users/12345/posts/67890/comments, that string must be copied into the map and hashed. A radix tree only walks down the tree, comparing one character or prefix per step — no full-path hash calculation, no dynamic memory allocation (the params slice can be pre-allocated).

RouterGroup and Route Registration

Gin's RouterGroup is a value type that stores a path prefix and a middleware list. When you call v1 := r.Group("/api/v1"), it creates a new RouterGroup that inherits the parent group's middleware:

type RouterGroup struct {
    Handlers HandlersChain  // this group's middleware
    basePath string          // path prefix
    engine   *Engine         // pointer to engine (where the routing tree lives)
    root     bool
}

func (group *RouterGroup) Group(relativePath string, handlers ...HandlerFunc) *RouterGroup {
    return &RouterGroup{
        Handlers: group.combineHandlers(handlers),  // merge parent middleware
        basePath: group.calculateAbsolutePath(relativePath),
        engine:   group.engine,
    }
}

When you register a route, middleware is merged with the handler into a single slice at registration time and stored in the routing tree:

// Registering GET /api/v1/users
// The handlers stored in the tree: [Logger, Auth, v1Auth, usersHandler]
v1.GET("/users", usersHandler)

This compile-time (registration-time) merge strategy is the key to Gin's zero runtime overhead — when a request arrives, there's no need to look up or compose middleware; it simply executes the pre-built slice in order.

`c.Abort()` vs Returning Directly

This is the most common misconception among Gin beginners:

func AuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        token := c.GetHeader("Authorization")
        if token == "" {
            c.JSON(401, gin.H{"error": "unauthorized"})
            return  // WRONG! This only returns from this function.
                    // The next handler in the chain will still execute!
        }
        c.Next()
    }
}

Let's understand why return is insufficient. Gin's middleware execution is a loop, not recursion:

// gin/context.go simplified
func (c *Context) Next() {
    c.index++
    for c.index < int8(len(c.handlers)) {
        c.handlers[c.index](c)  // call current handler
        c.index++               // automatically advance to next
    }
}

When AuthMiddleware's internal return executes, c.Next()'s loop continues and the next handler is called anyway.

The correct approach uses c.Abort():

func AuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        token := c.GetHeader("Authorization")
        if token == "" {
            c.AbortWithStatusJSON(401, gin.H{"error": "unauthorized"})
            return  // c.Abort() sets c.index to abortIndex (math.MaxInt8/2)
                    // subsequent handlers will not execute
        }
        c.Next()
    }
}

c.Abort() is remarkably simple in implementation:

const abortIndex int8 = math.MaxInt8 / 2  // 63

func (c *Context) Abort() {
    c.index = abortIndex  // set index past maximum, the for loop condition fails naturally
}

Parameter Binding and Validation

Gin integrates go-playground/validator/v10, enabling declarative validation through struct tags:

type CreateUserRequest struct {
    Name     string `json:"name"     binding:"required,min=2,max=50"`
    Email    string `json:"email"    binding:"required,email"`
    Age      int    `json:"age"      binding:"required,gte=18,lte=120"`
    Password string `json:"password" binding:"required,min=8"`
}

The difference between ShouldBindJSON and BindJSON:

BindJSON: On failure, automatically writes a 400 response — you cannot write any other response afterward.
ShouldBindJSON: On failure, only returns an error — you control the response content.

Always use ShouldBindJSON, because you almost always need a custom error format.

Level 3 · Code in Practice

Building a Complete REST API

We'll build a user management API demonstrating all core patterns:

package main

import (
    "errors"
    "fmt"
    "math/rand"
    "net/http"
    "strconv"
    "sync"
    "time"

    "github.com/gin-gonic/gin"
    "github.com/go-playground/validator/v10"
)

// ==================== Model Layer ====================

type User struct {
    ID        int64     `json:"id"`
    Name      string    `json:"name"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
}

// ==================== Request / Response Structs ====================

type CreateUserRequest struct {
    Name     string `json:"name"     binding:"required,min=2,max=50"`
    Email    string `json:"email"    binding:"required,email"`
    Password string `json:"password" binding:"required,min=8"`
}

type UpdateUserRequest struct {
    Name  string `json:"name"  binding:"omitempty,min=2,max=50"`
    Email string `json:"email" binding:"omitempty,email"`
}

// Unified response envelope
type Response struct {
    Code    int         `json:"code"`
    Message string      `json:"message"`
    Data    interface{} `json:"data,omitempty"`
}

func Success(c *gin.Context, data interface{}) {
    c.JSON(http.StatusOK, Response{Code: 0, Message: "ok", Data: data})
}

func Fail(c *gin.Context, httpCode int, appCode int, message string) {
    c.JSON(httpCode, Response{Code: appCode, Message: message})
}

// ==================== In-Memory Store (demo) ====================

type UserStore struct {
    mu      sync.RWMutex
    users   map[int64]*User
    counter int64
}

var store = &UserStore{users: make(map[int64]*User)}

func (s *UserStore) Create(req *CreateUserRequest) *User {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.counter++
    u := &User{
        ID:        s.counter,
        Name:      req.Name,
        Email:     req.Email,
        CreatedAt: time.Now(),
    }
    s.users[u.ID] = u
    return u
}

func (s *UserStore) Get(id int64) (*User, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    u, ok := s.users[id]
    return u, ok
}

func (s *UserStore) List() []*User {
    s.mu.RLock()
    defer s.mu.RUnlock()
    result := make([]*User, 0, len(s.users))
    for _, u := range s.users {
        result = append(result, u)
    }
    return result
}

func (s *UserStore) Update(id int64, req *UpdateUserRequest) (*User, bool) {
    s.mu.Lock()
    defer s.mu.Unlock()
    u, ok := s.users[id]
    if !ok {
        return nil, false
    }
    if req.Name != "" {
        u.Name = req.Name
    }
    if req.Email != "" {
        u.Email = req.Email
    }
    return u, true
}

func (s *UserStore) Delete(id int64) bool {
    s.mu.Lock()
    defer s.mu.Unlock()
    _, ok := s.users[id]
    if ok {
        delete(s.users, id)
    }
    return ok
}

// ==================== Handler Layer ====================

type UserHandler struct {
    store *UserStore
}

func (h *UserHandler) Create(c *gin.Context) {
    var req CreateUserRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        Fail(c, http.StatusBadRequest, 1001, formatValidationError(err))
        return
    }
    user := h.store.Create(&req)
    c.JSON(http.StatusCreated, Response{Code: 0, Message: "created", Data: user})
}

func (h *UserHandler) Get(c *gin.Context) {
    id, err := strconv.ParseInt(c.Param("id"), 10, 64)
    if err != nil {
        Fail(c, http.StatusBadRequest, 1002, "invalid user id")
        return
    }
    user, ok := h.store.Get(id)
    if !ok {
        Fail(c, http.StatusNotFound, 1003, "user not found")
        return
    }
    Success(c, user)
}

func (h *UserHandler) List(c *gin.Context) {
    users := h.store.List()
    Success(c, gin.H{"users": users, "total": len(users)})
}

func (h *UserHandler) Update(c *gin.Context) {
    id, err := strconv.ParseInt(c.Param("id"), 10, 64)
    if err != nil {
        Fail(c, http.StatusBadRequest, 1002, "invalid user id")
        return
    }
    var req UpdateUserRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        Fail(c, http.StatusBadRequest, 1001, formatValidationError(err))
        return
    }
    user, ok := h.store.Update(id, &req)
    if !ok {
        Fail(c, http.StatusNotFound, 1003, "user not found")
        return
    }
    Success(c, user)
}

func (h *UserHandler) Delete(c *gin.Context) {
    id, err := strconv.ParseInt(c.Param("id"), 10, 64)
    if err != nil {
        Fail(c, http.StatusBadRequest, 1002, "invalid user id")
        return
    }
    if !h.store.Delete(id) {
        Fail(c, http.StatusNotFound, 1003, "user not found")
        return
    }
    c.Status(http.StatusNoContent)  // 204 No Content, no response body
}

// ==================== File Upload ====================

func (h *UserHandler) UploadAvatar(c *gin.Context) {
    id, err := strconv.ParseInt(c.Param("id"), 10, 64)
    if err != nil {
        Fail(c, http.StatusBadRequest, 1002, "invalid user id")
        return
    }

    file, err := c.FormFile("avatar")
    if err != nil {
        Fail(c, http.StatusBadRequest, 1004, "avatar file is required")
        return
    }

    // Validate file size (2MB limit)
    if file.Size > 2*1024*1024 {
        Fail(c, http.StatusBadRequest, 1005, "file size must not exceed 2MB")
        return
    }

    // Validate MIME type (note: checking Content-Type header alone is insufficient
    // in production — you should also inspect the file's magic bytes)
    contentType := file.Header.Get("Content-Type")
    allowedTypes := map[string]bool{
        "image/jpeg": true,
        "image/png":  true,
        "image/webp": true,
    }
    if !allowedTypes[contentType] {
        Fail(c, http.StatusBadRequest, 1006, "only jpeg/png/webp images are allowed")
        return
    }

    // Save file (production should upload to object storage; local save for demo)
    dst := fmt.Sprintf("./uploads/avatar_%d_%s", id, file.Filename)
    if err := c.SaveUploadedFile(file, dst); err != nil {
        Fail(c, http.StatusInternalServerError, 5001, "failed to save file")
        return
    }

    Success(c, gin.H{"avatar_url": "/static/avatars/" + file.Filename})
}

// ==================== Validation Error Formatting ====================

func formatValidationError(err error) string {
    var ve validator.ValidationErrors
    if errors.As(err, &ve) {
        for _, e := range ve {
            switch e.Tag() {
            case "required":
                return fmt.Sprintf("field '%s' is required", e.Field())
            case "email":
                return fmt.Sprintf("field '%s' must be a valid email", e.Field())
            case "min":
                return fmt.Sprintf("field '%s' minimum length is %s", e.Field(), e.Param())
            case "max":
                return fmt.Sprintf("field '%s' maximum length is %s", e.Field(), e.Param())
            }
        }
    }
    return err.Error()
}

// ==================== Router Configuration ====================

func setupRouter() *gin.Engine {
    r := gin.New()  // don't use gin.Default(); configure middleware manually
    
    // Global middleware
    r.Use(gin.Recovery())
    r.Use(RequestIDMiddleware())
    r.Use(LoggerMiddleware())

    userHandler := &UserHandler{store: store}

    // API v1 route group
    v1 := r.Group("/api/v1")
    {
        users := v1.Group("/users")
        {
            users.POST("",            userHandler.Create)
            users.GET("",             userHandler.List)
            users.GET("/:id",         userHandler.Get)
            users.PUT("/:id",         userHandler.Update)
            users.DELETE("/:id",      userHandler.Delete)
            users.POST("/:id/avatar", userHandler.UploadAvatar)
        }
    }

    return r
}

func main() {
    r := setupRouter()
    r.Run(":8080")
}

Versioned Routes and Custom Error Handling

In real projects, APIs evolve over time. Versioned routes let you maintain multiple API versions simultaneously:

func setupVersionedRouter() *gin.Engine {
    r := gin.New()
    r.Use(gin.Recovery())

    // v1: JSON responses
    v1 := r.Group("/api/v1")
    v1.Use(AuthMiddleware())
    {
        v1.GET("/users", listUsersV1)
        v1.GET("/products", listProductsV1)
    }

    // v2: users endpoint has a new response format
    v2 := r.Group("/api/v2")
    v2.Use(AuthMiddleware())
    v2.Use(NewRateLimiter(100)) // v2 gets additional rate limiting
    {
        v2.GET("/users", listUsersV2)  // different response shape from v1
        // v2 /products doesn't exist — clients fall back to v1
    }

    // Custom 404 and 405 handlers
    r.NoRoute(func(c *gin.Context) {
        c.JSON(404, Response{Code: 4004, Message: "route not found"})
    })
    r.NoMethod(func(c *gin.Context) {
        c.JSON(405, Response{Code: 4005, Message: "method not allowed"})
    })

    return r
}

Level 4 · Deep Water

Gin vs Chi vs Echo: Performance Comparison

Framework selection often comes down to: which is faster? Before answering, we need to define "fast."

Benchmark results (from go-web-framework-benchmark, for reference only — real-world differences depend on scenario):

Framework	Route match (ns/op)	Memory (B/op)	allocs/op
Gin	~200	0	0
Chi	~300	304	2
Echo	~180	0	0
net/http	~120	0	0

Critical insight: These gaps are virtually invisible in real business applications. A database query takes 1–10ms; route matching takes 200ns — routing overhead is less than 0.02% of database latency.

More important dimensions for framework selection:

Chi: 100% compatible with net/http. Your middleware works with the standard library or any other framework. Best for teams that want control.
Echo: More modern API design, built-in WebSocket support, popular in Southeast Asian developer communities.
Gin: The largest ecosystem (highest star count), with many third-party middleware packages directly supporting Gin. Best for projects that need to move fast.

HTTP/2 Server Push

Server Push allows the server to proactively push CSS, JS, and other resources before the client requests them:

func indexHandler(w http.ResponseWriter, r *http.Request) {
    pusher, ok := w.(http.Pusher)
    if ok {
        // Tell the browser: you'll need these resources soon, here they are
        opts := &http.PushOptions{
            Header: http.Header{"Accept-Encoding": r.Header["Accept-Encoding"]},
        }
        if err := pusher.Push("/static/main.css", opts); err != nil {
            log.Printf("push failed: %v", err)
        }
        if err := pusher.Push("/static/app.js", opts); err != nil {
            log.Printf("push failed: %v", err)
        }
    }
    // Then render HTML normally
    tmpl.Execute(w, data)
}

Note: HTTP/2 Push was deprecated in Chrome 112+, because it's very difficult to get right in practice — the server doesn't know which resources are already in the browser's cache, causing unnecessary duplicate transfers. The modern alternative is <link rel="preload"> headers, letting the browser decide whether it needs to fetch a resource.

Long Polling vs SSE vs WebSocket: Choosing the Right Tool

Three real-time communication approaches, each with its optimal use case in Go:

Long Polling: The client sends a request; the server holds it open until new data is available, or returns an empty response on timeout.

func longPollHandler(c *gin.Context) {
    timeout := time.After(30 * time.Second)
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop()
    
    for {
        select {
        case <-timeout:
            c.JSON(200, gin.H{"data": nil, "timeout": true})
            return
        case event := <-getEventChannel(c.Param("roomID")):
            c.JSON(200, gin.H{"data": event})
            return
        case <-c.Request.Context().Done():
            return  // client disconnected
        }
    }
}

SSE (Server-Sent Events): Server pushes a unidirectional text stream; browsers natively support automatic reconnection.

func sseHandler(c *gin.Context) {
    c.Header("Content-Type", "text/event-stream")
    c.Header("Cache-Control", "no-cache")
    c.Header("Connection", "keep-alive")
    c.Header("X-Accel-Buffering", "no") // disable Nginx buffering

    ctx := c.Request.Context()
    flusher, _ := c.Writer.(http.Flusher)

    for {
        select {
        case <-ctx.Done():
            return
        case event := <-eventChan:
            fmt.Fprintf(c.Writer, "id: %d\n", event.ID)
            fmt.Fprintf(c.Writer, "event: %s\n", event.Type)
            fmt.Fprintf(c.Writer, "data: %s\n\n", event.Data)
            flusher.Flush()  // must flush immediately, otherwise data sits in the buffer
        }
    }
}

WebSocket: Full-duplex, for bidirectional real-time communication.

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        return true // production should validate Origin
    },
}

func wsHandler(c *gin.Context) {
    conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
    if err != nil {
        return
    }
    defer conn.Close()

    for {
        messageType, p, err := conn.ReadMessage()
        if err != nil {
            break
        }
        // Echo the message (real business logic would broadcast/route it)
        conn.WriteMessage(messageType, p)
    }
}

Decision tree:

Need server push, no client uplink needed → SSE (simpler, HTTP-friendly, better firewall traversal)
Need bidirectional real-time communication (chat, games, collaborative editing) → WebSocket
Target environment doesn't support SSE/WebSocket (old IE, restricted proxies) → Long Polling

Request ID Propagation

In a microservice architecture, one request may traverse multiple services. Request IDs let you trace the request chain across distributed logs:

const RequestIDKey = "X-Request-ID"

func RequestIDMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        // Prefer an upstream-injected Request ID (API Gateway / load balancer may set it)
        requestID := c.GetHeader(RequestIDKey)
        if requestID == "" {
            requestID = generateRequestID()
        }
        
        // Store in Context; downstream handlers retrieve via c.GetString(RequestIDKey)
        c.Set(RequestIDKey, requestID)
        
        // Write to response header so clients can report their trace ID
        c.Header(RequestIDKey, requestID)
        
        // Inject into http.Request's context so downstream HTTP calls can extract it
        ctx := context.WithValue(c.Request.Context(), RequestIDKey, requestID)
        c.Request = c.Request.WithContext(ctx)
        
        c.Next()
    }
}

func generateRequestID() string {
    b := make([]byte, 16)
    rand.Read(b)
    return fmt.Sprintf("%x-%x-%x-%x-%x", b[0:4], b[4:6], b[6:8], b[8:10], b[10:])
}

// Propagate Request ID in downstream HTTP calls
func callDownstreamService(ctx context.Context, url string) (*http.Response, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    if requestID, ok := ctx.Value(RequestIDKey).(string); ok {
        req.Header.Set(RequestIDKey, requestID)
    }
    return http.DefaultClient.Do(req)
}

This mechanism, combined with structured logging (e.g., zerolog or zap), lets you filter a complete request chain in Kibana or Grafana using a single Request ID.

Key Takeaways:

Go's net/http is goroutine-driven — one goroutine per connection — which is naturally suited for high concurrency.
Gin's performance advantage comes from radix tree routing and registration-time middleware chain assembly, not runtime dynamic composition.
c.Abort() sets an index flag; return only exits the current function — the two are not equivalent.
Framework performance differences are negligible in real business scenarios; choose based on ecosystem and team familiarity.
SSE is the simplest server-push solution; WebSocket is for genuinely bidirectional communication.

Rate this chapter

4.6 / 5 (5 ratings)

Web Services and Router Design

Web Services and Router Design

Level 1 · What You Need to Know

HTTP/1.1 vs HTTP/2 in Go

Why Gin Is Popular: Zero-Allocation Middleware Chain

Level 2 · How It Works

Gin's Routing Tree: The Radix Tree

RouterGroup and Route Registration

c.Abort() vs Returning Directly

Parameter Binding and Validation

Level 3 · Code in Practice

Building a Complete REST API

Versioned Routes and Custom Error Handling

Level 4 · Deep Water

Gin vs Chi vs Echo: Performance Comparison

HTTP/2 Server Push

Long Polling vs SSE vs WebSocket: Choosing the Right Tool

Request ID Propagation

💬 Comments

`c.Abort()` vs Returning Directly