GoLang что почитать чтобы норм вкатиться?
Публичный постПарни а тут же явно есть те кто с GoLang уже не первый год. Хочу внятно вкатиться и так чтобы ну более менее было в иделогии Go.
На текущий момент как web-фреймворк присмотрел Echo. В целом норм, но есть вопрос как там масштабироваться. Имею тяжелое прошлое ввиде java/spring. По этому подумал про DI. Нашел аж два от убера dig и от google wire. Вроде как wire более нативно. Или все же лучше как-то более просто квадратно гнездово? Предложения других фреймворков тоже рассматриваются с аргументацией почему лучше взять N вместо М. Buffalo если что смотрел. Что-то тяжеловато. Хочу полегче.
Как ORM присмотрел GORM. Норм или есть что получше?
Для конфигов взял viper. Норм? Или лучше взять другое?
В качестве управление зависимостями взял go modules. Нативно и работает. Или у него есть фатальный недостаток?
Ну и да какой-нибудь текст делай в go так, а не так приветствуется, а то я щас как налабаю как в жаве. :)
В Go комьюнити не очень приняты тяжеловестные подходы, тут стараются топить за прямолинейность и простоту и наиболее прямой путь.
ServeMuxизnet/http. Похоже сейчас популярен: https://github.com/gorilla/mux. Echo не так много кто использует да и полноценных веб фреймворков тут вообще почти нет и их используют какие-то маргиналы.А по поводу "что почитать".
Почитать:
- у Go очень хорошая стандартная документация.
- Effective go с оф сайта. https://golang.org/doc/effective_go.html В духе делай так и почему.
- Memory model in go: https://golang.org/ref/mem
- Сoncurrency in go от O'Reilly. Мне очень зашла, от базовых понятний конкуретности до различных паттернов: https://www.amazon.com/Concurrency-Go-Tools-Techniques-Developers/dp/1491941197
- Блог Дейва Чени, ну и его сборник как лушче писать на Go, ссылку тут уже давали: https://dave.cheney.net/practical-go
Посмотреть:
- Выборочные доклады с https://www.youtube.com/channel/UCx9QVEApa5BKLw9r8cnOFEA/videos
- Канал Good reviewer - Bad reviewer. Там code reviews с разбором разных кодовых баз, как с Go так и растом: https://www.youtube.com/channel/UC8_A5W8g7UV0pk0uL66iQAQ/videos
Еще, наверное, важный момент: в го тусовке есть некая очень сектансткая группа, которая строит монолиты внутри микросервисов и тащит какие-то практики и паттерны даже туда, куда бы не следовало.
Т.е. не нужно до освоения собственно поставки результатов длоя бизнеса бежать везде пихать DI, Репозитории с генераторами запросов и прочие вещи. Сначала нужно в голове освоить конвейер поставки сервисов и новой функциональности, а уже потом оптимизировать проблемные вещи и внедрять те паттерны, которые себя окупают. Тот же репозиторий вполне ок, если велика вероятность замены БД, а стоит недорого. Всратые нерды пишут обертки на все ради мнимой цели потом добиваться 99% покрытия моков юнит-тестами. На деле адеватный лид или архитектор это присечет, а если не присечет, то сраный круд будет выглядеть как нечто неподдерживаемое и слабо понятное.
Го простой ЯП: сначала осваиваем простые вещи и учимся приносить пользу, потом оптимизируем, а не наоборот. Сервис-ориентированная архитектура тем и хороша, что тут нет огромной цены ошибок: даже крупноватый сервис можно полностью переписать в обозримые сроки (А монолиты на го я, честно говоря, уже не очень представляю). А в бизнесе это может и не понадобится даже. Т.е. не надо переусложнять и оверинжинирить простые задачи.
Советую почитать статьи в блоге Дейва https://dave.cheney.net/practical-go
Его мнение в целом отражает мнение го коммьюнити
В целом согласен с @ashinkevich.
На голанге как правило работаем в сервис-ориентированной или микросервисной архитектуре. Соответственно, твой сервис скоре всего будет общаться с внешним миром через API или очереди сообщений.
Могу порекомендовать пзнакомиться с кодогенерацией: например, лучший вариант - описать апи специкацию с помощью опенапи и генерировать код генератором https://github.com/Foxcool/homework/tree/master/5-kbs-crud
Таким образом получаем четкую привязку кода к контрактам и не тратим время на бессмысленное ручное написание валидаторов и прочего иф кода.
Вайпер - норм тема. В примере выше можно посмотреть, как там описывать параметры конфигов.
По орм да, скорее перспективнее тема с генераторами кода, чем с орм (очень сложно дебажить ошибки было в том же ГОРМ, а по гибкости и мощности все равно не сравнится с ОРМ у динамических ЯП). В целом практика говорит о том, что если сервису не нужно опеспечивать транзакционность, то тащить РСУБД и потом мучаться с миграциями в плеяде сервисов не стоит.
http://golang-book.ru/chapter-01-gettting-started.html
https://go-tour-ru-ru.appspot.com/welcome/1
https://metanit.com/go/