Александр Павлюк

1. Интерфейсы лучше всего объявлять в тех местах, где они используются. То есть, внутри слоя бизнес-логики.
2. Репозиторий не должен возвращать/принимать никаких транспортно-специфичных типов (никаких *gorm.DB, пакета sql и прочих). Только структуры слоя бизнес-логики.
3. Репозитории лучше всего разделить, если у вас данных идут из монги, постгреса и редиса, это будут 3 разных репозитория, не надо их пытаться объединить под один интерфейс.
4. Передавать все зависимости чтобы сделать "внедрение" лучше всего в конструкторе. somepkg.New(pgRepo, mongoRepo). Внутри somepkg у вас будут определены интерфейсы под эти все репозитории, причем там будут только те методы, которые используются внутри этого пакета. В другом someotherpkg у нас будет определен уже другой интерфейс, содержащий методы, которые использует someotherpkg. Таким образом лучше видно что откуда используется и сохраняется чистота кода.
5. Делите обязательно все на слои, хендлеры импортят бизнес-логику, репозитории импортят бизнес-логику, но бизнес-логика не импортит ничего из хендлеров и репозиториев (для этого как раз интерфейсы и нужны). В итоге главная логика будет очень простая и изолированная от бойлерплейта транспортных слоев, не нужно будет переписывать тесты если что-то изменится в транспорте.

У вас проект не инициализирован, надо сделать go mod init имя
Вы пытаетесь добавить модуль как это делалось лет 7 назад, когда в Го не было модулей. Теперь надо все проекты делать через модули.
https://go.dev/blog/using-go-modules

После того как сделаете init, добавляйте модуль через
go get github.com/go-sql-driver/mysql@latest

Фабрику вообще не принято использовать в Го. Используйте вместо нее обычные конструкторы. Функцию New() в пакете, где у вас описан пользователь.

Когда с пользователем нужно что-то сделать, делайте это не методом самого типа пользователя, а функцией в пакете, который будет отвечать за проведение действий с пользователями. Если у вас разные пользователи и надо делать какую-то общую логику с ними, то пусть функции пакета, где будут действия с пользователем, принимают интерфейс, а не конкретный тип.

В интерфейсе перечисляйте только нужные для действий методы, а не все методы пользователя.

В вашей задаче нет циклов, почему в вопросе упоминается цикл?

У вас main написан так, что передаваевая в checkNil переменная никогда не будет nil.

Внутри checkNil вы перепутали равенство с неравенством. v != nil значит "v не равно nil", а у вас в этом случае выводится, что переменная пустая, хотя должно быть наоборот.

Го намного проще многих других языков, соответственно проще читать и понимать чужой код, что ценится в больших компаниях, где работает много людей. Плюсом ценится то, что довольно сложно выстрелить себе в ногу.

Тесты есть разные, Го примерно идет в ногу с Джавой и Шарпом, особенно в случае многопоточных нагруженных серверов. А если посмотреть сколько он потребляет при этом памяти, то даже выходит вперед по эффективности.

На Го очень просто писать многопоточность и асинхронность, не нужно думать об await-ах, каждая горутина имеет свой стек, что снимает с программиста много головной боли. Вся стандартная библиотека и большой набор библиотек с гитхаба из коробки поддерживают асинхронность и потоковую обработку данных, работать с этим сильно проще, чем в других языках. Соответственно, сложнее накосячить.

Но абстракций на Го очень мало, по сравнению с той же Джавой, он довольно бедно выглядит (что и дает простоту чтения кода). Это является минусом в определенных ситуациях, поэтому на Го стараются писать небольшие сервисы.

В итоге, легковесность горутин, легкость работы с ними и асинхронная модель из коробки (не создается тред на каждую рутину, а наоборот, рутины обрабатываются разными тредами по необходимости) привели к тому, что ниша Го это сервисы, которые упираются в ожидание ресурсов от каких-то внешних систем по сети. То есть, идеальный кейс для веб-сервера, который собирает под капотом инфу с БД и других сервисов. По сути такой сервис большую часть времени ждет ресурсов по сети, в Го это ожидание сделано очень эффективно.

Prometheus это про метрики

Grafana это тоже про метрики

Судя по коду, вы сделали поддержку трейсинга в вашем приложении, а чтобы смотреть трейсы, нужно развернуть интерфейс Jaeger. https://www.jaegertracing.io/

Есть статья на эту тему https://habr.com/ru/articles/710644/

Докер ничего не знает про http, он только пробрасывает tcp-коннекты до вашего приложения. Так что проблема точно где-то в вашем коде. Скорее всего какой-то из конфигов локально у вас подключается, а в докер не пробрасывается, поэтому какие-то из ограничений внутри приложения не снимаются.

502 Bad Gateway обычно вылезает, когда ваше приложение запрос куда-то перенаправляет. Вы с файлом что делаете, сохраняете на диск или куда-то отправляете?

func main() {
	cmd := exec.Command("ffmpeg", "-i", "input.ogg", "output.mp3")
	res, err := cmd.CombinedOutput()
	if err != nil {
		fmt.Println(string(res))
		fmt.Println("error executing command:", err)
		os.Exit(1)
	}
}

Естественно, на системе должен быть установлен ffmpeg, потому что тут вызывается внешняя программа.

Вы не сможете себе в портфолио добавить микросервисную архитектуру просто написав ее в пет-проекте. Настоящие микросервисы можно пощупать только на масштабах больших компаний и их инфраструктуре, так что устраивайтесь джуном/стажером в какой-нибудь Авито или Озон.

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

Сделайте лучше хороший проект-монолит, отработайте навыки языка, БД, развертывания, гита, итд... на одном проекте. Будет гораздо полезнее.

В Го по-умолчанию переменные передаются по значению (то есть, копируются на стеке), но есть нюансы.

1. Мапы и каналы всегда передаются по указателю.
2. У слайса на стеке только дескриптор, так что он копируется, но данные, на которые слайс указывал, остаются там же в памяти, где и были.
3. Если вы явно передаете указатель, то тут все очевидно.
4. У интерфейсов копируется дескриптор, но т.к. в дескрипторе указатель, то тут все как со слайсами.

Если http:
Взять какой-нибудь хороший роутер, например https://github.com/julienschmidt/httprouter
И на его основе сделать врапперы и мидлвари под себя по необходимости.
Если работаете в какой-то конторе, то там уже должен быть фреймворк для микросервисов, заточенный под инфраструктуру компании. Потому что если сервисы делаются все по-разному, это беда.

Если grpc:
Особых вариантов нет, нужно использовать protoc.
При необходимости подключить плагины, чтобы был сваггер и гейтвей в http
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway
github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2

Почему не предлагаю какой-то большой конкретный фреймфорк? Если бы вы сказали, что веб-приложения будете писать, можно было бы посоветовать что-то типа gin, но вы сказали про микросервисы. С ними такая специфика, что надо как конструктор собирать себе стек под задачу, иначе будет неудобно.