Какие production-риски есть у Fiber (Go framework): blocking code, connection pooling, config, auth, observability, deploy или graceful shutdown?

Connection pooling

Fiber не управляет пулом соединений — это обязанность драйвера. Для PostgreSQL с pgx:

package main

import (
	"context"
	"time"

	"github.com/jackc/pgx/v5/pgxpool"
)

func newPool(dsn string) (*pgxpool.Pool, error) {
	cfg, err := pgxpool.ParseConfig(dsn)
	if err != nil {
		return nil, err
	}
	cfg.MaxConns = 20
	cfg.MinConns = 5
	cfg.MaxConnLifetime = 30 * time.Minute
	cfg.MaxConnIdleTime = 5 * time.Minute
	return pgxpool.NewWithConfig(context.Background(), cfg)
}

Без явных лимитов каждый хендлер открывает новое соединение — БД падает под нагрузкой.

Blocking code в хендлерах

Fiber использует fasthttp, который работает на goroutine-per-request с повторным использованием буферов. Блокирующие вызовы (os.ReadFile, тяжёлые SQL без таймаутов, внешние HTTP без дедлайнов) блокируют горутину и снижают concurrency. Всегда передавайте context.WithTimeout в запросы к БД и HTTP-клиентам.

Гонки с ctx (fasthttp.RequestCtx)

Fiber передаёт *fiber.Ctx, который ссылается на fasthttp.RequestCtx. После завершения хендлера этот контекст возвращается в пул и перезаписывается. Если вы передаёте ctx в горутину, данные окажутся невалидными:

// НЕПРАВИЛЬНО — гонка данных
app.Get("/async", func(c *fiber.Ctx) error {
	go process(c.Body()) // c.Body() невалиден после return
	return c.SendStatus(202)
})

// ПРАВИЛЬНО — копируем данные до запуска горутины
app.Get("/async", func(c *fiber.Ctx) error {
	body := make([]byte, len(c.Body()))
	copy(body, c.Body())
	go process(body)
	return c.SendStatus(202)
})

Аутентификация и конфигурация

Fiber предоставляет middleware github.com/gofiber/contrib/jwt для JWT. Типичная ошибка — хранить секрет в коде вместо переменных окружения. Используйте os.Getenv("JWT_SECRET") и проверяйте при старте.

Observability

Встроенного трейсинга нет. Подключайте github.com/gofiber/contrib/otelfiber для OpenTelemetry и github.com/ansrivas/fiberprometheus для метрик:

import (
	"github.com/ansrivas/fiberprometheus/v2"
	"github.com/gofiber/contrib/otelfiber"
)

app.Use(otelfiber.Middleware())

prometheus := fiberprometheus.New("my_service")
prometheus.RegisterAt(app, "/metrics")
app.Use(prometheus.Middleware)

Graceful shutdown

Без graceful shutdown in-flight запросы обрываются при деплое:

package main

import (
	"os"
	"os/signal"
	"syscall"

	"github.com/gofiber/fiber/v2"
)

func main() {
	app := fiber.New(fiber.Config{
		IdleTimeout: 5 * time.Second,
	})

	quit := make(chan os.Signal, 1)
	signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)

	go func() {
		<-quit
		_ = app.Shutdown() // ждёт завершения активных запросов
	}()

	if err := app.Listen(":3000"); err != nil {
		panic(err)
	}
}

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

• Использование ctx после возврата хендлера — fasthttp переиспользует RequestCtx; любое чтение в отложенной горутине даёт мусорные данные.
• Отсутствие таймаутов на исходящие запросы — зависший upstream блокирует горутину навсегда и исчерпывает пул.
• Не настроен ReadTimeout / WriteTimeout — slow-client атака держит соединение открытым.
• Передача стандартного net/http middleware — Fiber не совместим с http.Handler; для адаптации нужен adaptor.HTTPHandler().
• Отсутствие rate limiting — используйте github.com/gofiber/fiber/v2/middleware/limiter или внешний Nginx.
• Логгирование без структуры — fmt.Println в хендлерах не поддаётся парсингу в ELK/Loki; подключайте zerolog или zap.
• Паника без recover — один хендлер с nil pointer кладёт весь сервер; используйте middleware/recover.
• Игнорирование GOMAXPROCS — в Docker без uber-go/automaxprocs Go может видеть только 1 CPU.

• Говорить только о запуске Fiber (Go framework), но не об эксплуатации
• Не упоминать observability, обновления, безопасность и rollback
• Описывать риски абстрактно, без способов их снижать

• Видит production-риски Fiber (Go framework)
• Говорит про monitoring, rollout, rollback и безопасность
• Умеет ранжировать риски по вероятности и влиянию