Comments 4
При создании веб-API на Go, фреймворк Gin часто становится первым
Да, особенно в галерах, где важнее быстро наклепать продукт и забыть о нем. А в реальности же из-за несовместимости Gin со стандартным net/http (привет, Chi!) весь API будет зависеть именно от него и при смене роутера придется переписывать абсолютно все хэндлеры.
Пункт 1. Причем тут вообще Gin? Сервер создается и настраивается из пакета net/http и конфигурируется как душе угодно, Gin тут идет всего лишь как роутер, будь то горилла или http.ServeMux
Пункт 2. Обычный паттерн любого роутера, в чем тут особенность Gin?
Пункт 4. Опять же, каким боком тут Gin и его особенности? Вы останавливаете сервер, а не роутер
Ощущение, что автор статьи не работал ни с чем, кроме Gin и выдает его за волшебный способ реализации API, к тому же не различает понятия сервера и роутера. И где же тут "скрытые фишки"?
У меня везде используется gin просто потому, что до того как стандартный подтянулся по фичам не было ничего. И теперь переходить уже фсё, унаследовано. Статья автора для меня и таких как я полезна.
Везде используете Gin, но миддлварь для рекавери для вас был скрытой фишкой? Потому что все остальное кроме валидации с Gin никак не связано
Echo как по мне лучшая альтернатива.
Что делать с Gin когда надо добавить новые поля в контекст? Да, там есть мапа для кастомных ключей, но нет типизации, нет понимания что там вообще может оказаться. Как это использовать не очень понятно.
В Echo контекст - это интерфейс, а не структура. Поэтому туда супер просто запихнуть любые данные: токен сессии, данные о юзере полученные из mw и т.д.
Топ 5 возможностей Gin, которые должен знать каждый Go-разработчик