В каких backend-проектах Fiber (Go framework) является сильным выбором, а где лучше выбрать более простой или другой стек?

Когда Fiber — сильный выбор

Fiber построен поверх fasthttp и достигает пропускной способности 150 000–300 000 запросов/с на одном ядре в бенчмарках. Он подходит для:

• Высоконагруженных REST/JSON API — фоновая обработка событий, агрегаторы, gateway-сервисы, где каждые 100 мкс задержки критичны.
• Stateless микросервисов — edge-proxy, rate-limiter, короткий pipeline трансформации данных.
• WebSocket real-time стримов — Fiber поддерживает (*fiber.App).Use("/ws", websocket.New(handler)) через пакет github.com/gofiber/contrib/websocket.
• Serverless / тонкие контейнеры — бинарник ~8 МБ, время старта <10 мс.

Когда лучше выбрать другой стек

• net/http + Chi / ServeMux (Go 1.22+) — если команда небольшая и нет жёстких требований по throughput; стандартная библиотека проще поддерживать.
• Gin — если нужна зрелая экосистема middleware и уже используется net/http-совместимый код (fasthttp несовместим с http.Handler).
• Echo — для монолитов с OpenAPI-генерацией через oapi-codegen.
• gRPC (google.golang.org/grpc) — для межсервисного взаимодействия с типизированными контрактами Protobuf.

Пример: минимальный Fiber API

package main

import (
	"log"

	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/logger"
	"github.com/gofiber/fiber/v2/middleware/recover"
)

func main() {
	app := fiber.New(fiber.Config{
		ReadTimeout:  5 * time.Second,
		WriteTimeout: 10 * time.Second,
		Prefork:      false, // true только на bare-metal Linux (SO_REUSEPORT)
	})

	app.Use(recover.New())
	app.Use(logger.New())

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

	log.Fatal(app.Listen(":8080"))
}

Ограничения fasthttp и их последствия

Fiber использует fasthttp, который не совместим с net/http.Handler. Это означает:

• Нельзя напрямую использовать middleware из экосистемы net/http (например, gorilla/handlers, negroni).
• Объект fiber.Ctx переиспользуется через sync.Pool — нельзя хранить его вне goroutine обработчика.
• Некоторые клиентские библиотеки тестирования ожидают http.Handler — нужен app.Test(req) из самого Fiber.

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

• Ctx не потокобезопасен — нельзя передавать *fiber.Ctx в горутины; данные нужно скопировать до запуска горутины.
• Prefork на macOS не работает корректно — Prefork: true использует SO_REUSEPORT, который на Darwin ведёт себя иначе, чем на Linux.
• Несовместимость с net/http middleware — импорт popular-библиотек типа prometheus/client_golang требует дополнительного адаптера или стандартного adaptor.HTTPHandler().
• Body parsing по умолчанию лимитирован 4 МБ — без явного BodyLimit большие загрузки получат 413.
• Сессии требуют явного store — session.New() использует in-memory по умолчанию, что ломается при нескольких репликах.
• Версии v2 и v3 несовместимы по API — при обновлении нужно вручную мигрировать маршруты и middleware.
• Отладка контекста сложнее — отсутствие стандартного context.Context в fiber.Ctx усложняет интеграцию с трейсингом (OpenTelemetry требует обёртки).

• Выбирать Fiber (Go framework) по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где Fiber (Go framework) будет плохим выбором

• Называет критерии выбора Fiber (Go framework)
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу