Как определить middleware в Fiber и каков порядок его выполнения?

Определение middleware

package main

import (
	"fmt"
	"github.com/gofiber/fiber/v2"
)

// Middleware — это функция, принимающая *fiber.Ctx и возвращающая error
func TimingMiddleware(c *fiber.Ctx) error {
	// Код ДО следующего обработчика
	start := time.Now()

	// Передаём управление следующему middleware или хэндлеру
	err := c.Next()

	// Код ПОСЛЕ (выполняется когда хэндлер вернул управление)
	duration := time.Since(start)
	fmt.Printf("%s %s — %v\n", c.Method(), c.Path(), duration)

	return err
}

func AuthMiddleware(c *fiber.Ctx) error {
	if c.Get("X-API-Key") != "secret" {
		// Не вызываем c.Next() — цепочка обрывается
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
			"error": "unauthorized",
		})
	}
	return c.Next()
}

func main() {
	app := fiber.New()

	// Глобальные middleware — применяются ко всем маршрутам
	// Порядок: TimingMiddleware -> AuthMiddleware -> хэндлер
	app.Use(TimingMiddleware)
	app.Use(AuthMiddleware)

	app.Get("/data", func(c *fiber.Ctx) error {
		return c.JSON(fiber.Map{"data": "ok"})
	})

	// Middleware только для группы маршрутов
	admin := app.Group("/admin")
	admin.Use(func(c *fiber.Ctx) error {
		// выполняется только для /admin/*
		c.Locals("role", "admin")
		return c.Next()
	})
	admin.Get("/stats", func(c *fiber.Ctx) error {
		return c.SendString("admin only")
	})

	// Middleware для конкретного маршрута (inline)
	app.Get("/special", AuthMiddleware, func(c *fiber.Ctx) error {
		return c.SendString("special route")
	})

	app.Listen(":3000")
}

Middleware в Fiber: определение и порядок выполнения

Middleware в Fiber — это обычный обработчик с сигнатурой func(*fiber.Ctx) error, который вызывает c.Next() для передачи управления следующему обработчику в цепочке. Порядок регистрации через app.Use() определяет порядок выполнения.

Порядок выполнения (схема)

# Запрос идёт через middleware в порядке регистрации:
# Middleware1.before -> Middleware2.before -> Handler
# Handler -> Middleware2.after -> Middleware1.after
#
# Если Middleware2 НЕ вызывает c.Next():
# Middleware1.before -> Middleware2 (возвращает ответ)
# (Handler и Middleware1.after НЕ выполняются)

Возврат ошибки vs прерывание цепочки

// Вариант 1: возвращаем ошибку — она пойдёт в ErrorHandler
func RateLimitMiddleware(c *fiber.Ctx) error {
	if isLimited(c.IP()) {
		return fiber.NewError(fiber.StatusTooManyRequests, "rate limit exceeded")
	}
	return c.Next()
}

// Вариант 2: отвечаем напрямую и возвращаем nil — ErrorHandler не вызывается
func CORSMiddleware(c *fiber.Ctx) error {
	c.Set("Access-Control-Allow-Origin", "*")
	if c.Method() == fiber.MethodOptions {
		return c.SendStatus(fiber.StatusNoContent) // цепочка прервана
	}
	return c.Next()
}

Подводные камни

• app.Use() без пути применяется ко всем маршрутам. В отличие от Express, Fiber применяет middleware к маршрутам, зарегистрированным ПОСЛЕ него. Middleware, добавленный после маршрута, не обрабатывает этот маршрут.
• Забытый c.Next() блокирует ответ. Если middleware не вызвал ни c.Next(), ни методы отправки ответа, клиент получит пустой ответ.
• Двойная запись в ответ. Если и middleware, и хэндлер вызывают c.JSON(), второй вызов вызовет ошибку fasthttp «response already sent».
• Код после c.Next() выполняется всегда. Даже если хэндлер вернул ошибку, код после c.Next() в middleware выполнится — учитывайте это при работе с ресурсами.
• Middleware для группы не применяется к маршрутам вне группы. Регистрация admin.Use(auth) не защищает app.Get("/admin/hack"), зарегистрированный напрямую через app.
• Порядок глобального и группового middleware. Глобальный app.Use() выполняется перед групповым, даже если группа зарегистрирована первой.

• Давать ответ про middleware и порядок выполнения в Fiber только на уровне определения, не показывая поведение в реальном приложении.
• Игнорировать границы ответственности вокруг темы «middleware и порядок выполнения в Fiber»: кто отменяет работу, кто владеет ресурсом и где формируется ответ клиенту.
• Не связывать middleware и порядок выполнения в Fiber с observability, тестированием или безопасностью, когда это влияет на продакшен-поведение.

• Точно объясняет, что именно делает middleware и порядок выполнения в Fiber и где это используется в Go-коде.
• Связывает middleware и порядок выполнения в Fiber с корректным lifecycle запроса, отменой, конкурентностью или конфигурацией сервера там, где это уместно.
• Не изобретает API и опирается на реальные контракты официальной документации.