В последнее время всё чаще слышу "как вы живёте в Go без фреймворков, это же неэффективно"
Ну блин, а зачем он нужен? Если пишешь типичный микросервис, REST + кафка, например:
http-сервер встроен прям в стандартную либу, он работает просто отлично.
Роутинг http-запросов есть в стандартной либе, если надо какие-то расширенные возможности, полезные мидлвары и т.д - юзаешь либу chi или аналог
Логгер прекрасный встроен из коробки (json, уровни логирования и т.д).
Ну кафка да, подключаешь либу.
Всякие там генераторы крудов на фиг не нужны. Потому что в реальности никогда не бывает чистого круда. Обычно при создании сущности нужна одна структура данных, при редактировании в админке - другая, при выводе в разных местах нужно джойнить разные совершенно таблицы туда.
Валидация данных делается с помощью либы.
ORM в мире Go редко используется, но если прям надо, ну подключи gorm
Всякие там dependency injection системы в микросервисах вообще не нужны, но если код сервиса разрастётся, то можно потом прикрутить либу (uber-go/fx, например)
Метрики для прометея - либу взять, прикрутить не сложно. Она сразу выдаёт параметры самого рантайма (количество горутин, памяти и т.д), а свои кастомные тоже прикручиваются не особо сложно, например в мидлвару запихать.
Профайлер в Go приделывается парой строк кода
Подход "convention over configuration", которые так любят фреймворки, считаю ошибкой. Когда тебе создаётся 100500 папок, в которые надо что-то сунуть в нужные места (которые надо знать наизусть), всё вокруг отнаследовано от неведомых классов, которые тоже надо знать. А прикрутить что-то стороннее/нестандартное внутрь этого монстра - задача со звёздочкой.
Мне, короче, больше нравится парадигма "Явное лучше неявного".
Фреймворки лучше подходят для задач "сделай сайт целиком", с авторизацией, сессиями, шаблонами и т.д, но это не является типичным юзкейсом языка Go
🫥 Cross Join
⠀
Post #460
3.2K
- 👍 75
- 🤡 15
- ❤ 4
- 🔥 2