Вы упомянули, что используете 2 типа для чтения/записи бд. Непонятно что такое типы, но мы открывали 2 коннекта к базе и оборачивали в структуру, а когда надо чтото делать с бд, то явно указываем в какую реплику идти. Судя по видео вы пытаетесь из го сделать джаву, что противоречит философии го. Есть фидбэк от людей, которые приходили к вам в команду и глядя на репозиторий говорили, что это очень круто/отстойно? Как я понял у вас есть опыт разработки монолитов на го. Не могли бы вы поделиться причинами такого выбора и какими нибудь сравнительными тестами(rps, memory, profiler...) монолита с микросервисами на го? Да и вообще про монолиты на го было бы интересно узнать(на сколько сложно поддерживать, какие трудности есть, как воююете с жирными бинарниками, какой размер монолита...)
Не хватает про shared зависимости темы. Часто в ногу стреляют себе не понимая, что создается, а что переиспользуется. Каждый инжектор создает по умолчанию для себя новые зависимости независимые. Если использовать более 1 инжектора и где-то в графе зависимостей нужен будет общий логер например или коннект к базе данных, то там для каждого графа зависимостей в рамках инжектора будут провайдеры вывываться и возвращать новые инстансы (если провайдер не сделан специально как singleton возврат). В symfony DI это опция `shared` регулирует явно например. Об этом стоило бы подсветить и показать как оба варианта решать в wire, чтобы дать более полные знания
Можно сказать, что в Wire всё что создаётся в процессе "shared", то есть созданный единожды *log.Logger будет прокидываться далее во все инжекторы, которые требуют *log.Logger. Это можно заметить по сгенерированному файлу. Более того, нельзя использовать два инжектора, которые будут возвращать инстансы одного и того же типа, это тоже подсветил в разделе "5. Типы значений в Wire или ошибка multiple bindings for". Тут как раз наоборот, если нужно два логгера, то у каждого должен быть свой тип (через type aliasing, например), и для каждого типа свой провайдер. Тогда создадутся два независимых инстанса.
@@VyacheArt Да , все так, в гайде об этом не хватило информации, хотя он выглядит достаточно основательным и полным. Если будет вторая часть, то этот гайд с дополнением можно смело давать новичкам, зная что он полный
Видео 💥 Спасибо за труд! Дальнейших успехов!
Спасибо!
Спасибо большое. Будет продолжение, но уже с reflection based DI?
Думаю да, в будущем расскажу про uber/dig и defval/di. Спасибо!
Вы упомянули, что используете 2 типа для чтения/записи бд. Непонятно что такое типы, но мы открывали 2 коннекта к базе и оборачивали в структуру, а когда надо чтото делать с бд, то явно указываем в какую реплику идти.
Судя по видео вы пытаетесь из го сделать джаву, что противоречит философии го. Есть фидбэк от людей, которые приходили к вам в команду и глядя на репозиторий говорили, что это очень круто/отстойно?
Как я понял у вас есть опыт разработки монолитов на го. Не могли бы вы поделиться причинами такого выбора и какими нибудь сравнительными тестами(rps, memory, profiler...) монолита с микросервисами на го? Да и вообще про монолиты на го было бы интересно узнать(на сколько сложно поддерживать, какие трудности есть, как воююете с жирными бинарниками, какой размер монолита...)
Не хватает про shared зависимости темы. Часто в ногу стреляют себе не понимая, что создается, а что переиспользуется. Каждый инжектор создает по умолчанию для себя новые зависимости независимые. Если использовать более 1 инжектора и где-то в графе зависимостей нужен будет общий логер например или коннект к базе данных, то там для каждого графа зависимостей в рамках инжектора будут провайдеры вывываться и возвращать новые инстансы (если провайдер не сделан специально как singleton возврат). В symfony DI это опция `shared` регулирует явно например. Об этом стоило бы подсветить и показать как оба варианта решать в wire, чтобы дать более полные знания
Можно сказать, что в Wire всё что создаётся в процессе "shared", то есть созданный единожды *log.Logger будет прокидываться далее во все инжекторы, которые требуют *log.Logger. Это можно заметить по сгенерированному файлу. Более того, нельзя использовать два инжектора, которые будут возвращать инстансы одного и того же типа, это тоже подсветил в разделе "5. Типы значений в Wire или ошибка multiple bindings for". Тут как раз наоборот, если нужно два логгера, то у каждого должен быть свой тип (через type aliasing, например), и для каждого типа свой провайдер. Тогда создадутся два независимых инстанса.
@@VyacheArt Да , все так, в гайде об этом не хватило информации, хотя он выглядит достаточно основательным и полным. Если будет вторая часть, то этот гайд с дополнением можно смело давать новичкам, зная что он полный
белая тема это сильно, чуть не ослеп
1
жаль ток утиная типизация интерфейсов пропадает
Ну она фактически остаётся, просто явно нужно биндить интерфейс и имплементацию 🙂
Но неявно да, оно не славливается
это точно проще чем руками создать структурки?