Что обычно используют для создания веб-сервиса на Go

Что проверяют

Понимаете ли вы, что на Go стандартной библиотеки хватает для большинства сервисов, и знаете ли, что добавляют сверху в реальном проекте. Ответ одним названием фреймворка считают слабым.

Как отвечать

• База это net/http. С версии 1.22 у http.ServeMux появились методы и параметры в шаблонах: mux.HandleFunc("GET /users/{id}", h) и r.PathValue("id"). Раньше ровно за этим и брали роутер.
• Роутеры и фреймворки: chi совместим с http.Handler и потому почти бесплатен, gin и echo дают свой контекст и пишутся быстрее, но обработчики перестают быть стандартными.
• Сервер поднимают явно, а не вызовом http.ListenAndServe: без таймаутов зависший клиент держит соединение сколько угодно.

srv := &http.Server{
    Addr: ":8080", Handler: mux,
    ReadHeaderTimeout: 5 * time.Second,
    WriteTimeout: 10 * time.Second,
}

• Промежуточные слои это обычная обёртка func(http.Handler) http.Handler: логирование, восстановление после паники, идентификатор запроса, авторизация.
• База данных: database/sql с драйвером pgx, поверх sqlx или sqlc; полноценную ORM берут реже и осознанно.
• Остальное: конфиг из переменных окружения, структурные логи через log/slog, тесты на httptest, корректное завершение по сигналу через Shutdown.

Где спотыкаются

Называют только фреймворк и теряются, когда просят то же самое на стандартной библиотеке. Это ожидаемый следующий вопрос: интерфейс http.Handler один и тот же, фреймворк лишь надстройка над ним.

Второе: игнорируют контекст запроса. Клиент отключился, а обработчик продолжает ходить в базу и жечь соединения. Контекст нужно пробрасывать во все вызовы и уважать его отмену.

Третье: забывают, что каждый запрос обрабатывается своей горутиной. Общая карта или счётчик без синхронизации дают гонку, которая проявится под нагрузкой и не воспроизведётся локально. Прогон тестов с флагом гонки ловит это заранее.