1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

2. Чистая архитектура это книжка, там в основном про solid. Реклмендую прочитать на выходных, чтобы такие вопросы не возникали. А разнообразия «чистых архитектур» на гитхабе, это просто перекладывание папочек и попытка повторить нейминг, предложенный в книжке. Хотя в той же книжке написано, что чистая архитектура не регламентирует структуру и архитектуру проекта

1. В го не особо популярны, есть вроде uber fx, wire. 2. It depends. От команды, от проекта, кому как удобно. 3. Мне кажется горму далеко до алхимии. Асинкпг это вроде как драйвер постгреса на базе asyncio, т.е асинхронный, async await в голанге нет, но есть pgx достаточно мощный 4. в го более явная обработка ошибок, if err != nil{ return err } 5. Must в названии функции обозначает, что эта функция вызовет панику если чет пошло не так.

2. Чистая архитектура это книжка, там в основном про solid. Реклмендую прочитать на выходных, чтобы такие вопросы не возникали. А разнообразия «чистых архитектур» на гитхабе, это просто перекладывание папочек и попытка повторить нейминг, предложенный в книжке. Хотя в той же книжке написано, что чистая архитектура не регламентирует структуру и архитектуру проекта

Я читал и это не про солид А про слои и их ответственность Ну и про перфокарты, телеграфные столбы и воду от мартина😁

Я читал и это не про солид А про слои и их ответственность Ну и про перфокарты, телеграфные столбы и воду от мартина😁

А солид про что тогда?

Так там треть книги примерно про солид

вроде 50%

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

1. Слабо актуально 2. Польза есть 4. возвращать надо. Под стратегию не понял, что имеешь в виду

4. if err

это направление зависимостей, не слои

Правильный ответ "Слои", как я понял

не понял, что значит протекают

Когда низлежащий слой знает о высшем, например, из-за прямых импортов (Dependency inversion principle) или отсутсвия интерфейсов в некоторых местах. Но это же всё про solid...

1. В го не особо популярны, есть вроде uber fx, wire. 2. It depends. От команды, от проекта, кому как удобно. 3. Мне кажется горму далеко до алхимии. Асинкпг это вроде как драйвер постгреса на базе asyncio, т.е асинхронный, async await в голанге нет, но есть pgx достаточно мощный 4. в го более явная обработка ошибок, if err != nil{ return err } 5. Must в названии функции обозначает, что эта функция вызовет панику если чет пошло не так.

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

1. Лучше написать свою реализацию разрешения зависимостей, это достаточно просто, тебе скорее всего не нужна сложная библиотека для решения твоих проблем. Да и нужно понять есть ли проблема, для большинства проектов DI не нужен. 2. Чистая архитекрута это как религия - у каждого своя, я бы не усложнял проект реализуя "свое видение чистой архитектуры", пользы от нее не так много как много хайпа. 3. За ORM в го тебя на кол посадят, во первых зачем брать быстрый язык, чтобы замедлять его какими-то орм, когда просто можно писать на абсолютно всем понятном SQL. Во вторых из-за низкой популярности орм в го горм развивается очень медленно и имеет кучу багов, тебе оно не нужно, в проде его нет, на собесах тебя про него не спросят. Есть pgx, но лучше начать с нативных инструментов языка database/sql. 4. Каждый раз явно возвращать ошибку, вспомни про тот же принцип в питоне что явное лучше не явного и забудь про try-except)

3. Да я и так работал с сырым sql, просто местами устаешь писать под каждый фильтр where запрос 4. Там удобно сделано, ты в любом месте рейзишь ошибку, а на уровне приложения перехватил и все готово😁

3. Да я и так работал с сырым sql, просто местами устаешь писать под каждый фильтр where запрос 4. Там удобно сделано, ты в любом месте рейзишь ошибку, а на уровне приложения перехватил и все готово😁

пайтон мой основной язык был долгое время, спасибо)

Сложно перейти было? Или что самое сложное было?

3. Да я и так работал с сырым sql, просто местами устаешь писать под каждый фильтр where запрос 4. Там удобно сделано, ты в любом месте рейзишь ошибку, а на уровне приложения перехватил и все готово😁

Что значит устанешь под фильтр писать запрос? Там же не 10 файлов надо написать, а пару строк

Что значит устанешь под фильтр писать запрос? Там же не 10 файлов надо написать, а пару строк

Есть таблица пользователей 1 Запрос я хочу за последний день кто зарегался 2 запрос кто не активировал аккаунт 3 запрос по дате рождения И тд А потом добавилась новая колонка вип клиент или нет И все запросы нужно править, добавляя эту колонку

причем в gorm много вариантов записи условия where)) как по мне легче в sql писать так уж точно))

Есть таблица пользователей 1 Запрос я хочу за последний день кто зарегался 2 запрос кто не активировал аккаунт 3 запрос по дате рождения И тд А потом добавилась новая колонка вип клиент или нет И все запросы нужно править, добавляя эту колонку

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

golang

type UserDBModel struct { ID uuid.UUID `db:"user_id"` UserName string `db:"username"` FullName string `db:"full_name"` Email string `db:"email"`

1. Лучше написать свою реализацию разрешения зависимостей, это достаточно просто, тебе скорее всего не нужна сложная библиотека для решения твоих проблем. Да и нужно понять есть ли проблема, для большинства проектов DI не нужен. 2. Чистая архитекрута это как религия - у каждого своя, я бы не усложнял проект реализуя "свое видение чистой архитектуры", пользы от нее не так много как много хайпа. 3. За ORM в го тебя на кол посадят, во первых зачем брать быстрый язык, чтобы замедлять его какими-то орм, когда просто можно писать на абсолютно всем понятном SQL. Во вторых из-за низкой популярности орм в го горм развивается очень медленно и имеет кучу багов, тебе оно не нужно, в проде его нет, на собесах тебя про него не спросят. Есть pgx, но лучше начать с нативных инструментов языка database/sql. 4. Каждый раз явно возвращать ошибку, вспомни про тот же принцип в питоне что явное лучше не явного и забудь про try-except)

1. актуальность-хуяктуальность. Я использую самописный контейнер как замену application.go, для меня это наименьшее зло. 2. Смотря что понимать под чистой архитектурой. Если брать как ее проявление гексагональную архитектуру - да, это прикольно нужно и важно, но есть и ребята, кто зовет БД из ручки - ничего с этим страшного прям у них нет. Проблемы начинаются как обычно при рефаке или на хайлоаде или в распределенных командах. 4. Можешь и не возвращать, потом гадать откуда трабл. Похожая штука на эксепшн - паника, ее тоже можно отловить, но это не го-way. 5. Стайлгайды лучше загугли, а вот Must при инициализации обычно указывает на фабрики, которые паничат, если что-то не случилось. Например, если коннект к базе не прошел, а у нас все приложение завязано на нее - сразу кинуть панику вместо пятисоток на ответ от ручек.

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

она своя только у тех, кто смысла ее не понимает, который про простые истины: делай зависимости норм, чтобы не огребать при изменениях

То есть у 100% разработчиков) каждый из них говорит что остальные "не понимают смысла" 😂

Если ужать "весь смысл" до одного предложения, то это будет "зависимости направлены в одну сторону" ну или "БЛ ни от чего не зависит". Полно людей, которые это понимают. Тех, кто не понимает, к сожалению, тож полно.

1. https://github.com/golobby/container, но только для сбора зависимостей не дальше cmd 2. Да. 3. Почти. Pgx или любой другой драйвер. В го нет разноцветных функций. 4. Да. Под стратегией хз что имеешь ввиду. 5. https://go.dev/blog/, https://google.github.io/styleguide/go/, https://github.com/uber-go/guide

4. https://refactoring.guru/ru/design-patterns/strategy

Я знаю что такое. Не понимаю что ты хочешь стратегировать при обработке ошибки.

Вот нашел уже примеры, как подругому решить это

Конфикт какой-то в домене… говнокод какой-то

Почти 10к звезд на гитхубе

Тысячи мух не могут ошибаться..

Я позитивно мышлю Поэтому тысячи пчел не могут ошибаться..

https://github.com/bxcodec/go-clean-arch/tree/master

1. Какой di контейнер юзать или актуальность его? 2. Чистая архитектура нужна или нет? 3. Gorm это аналог алхимии? А есть аналог asyncpg? 4. Эксепшенов тоже нет? Каждый раз нужно ошибку возвращать и проверять через стратегию? 5. Есть ссылка на стайлгайд например почему мы должны функцию называть с Must которая инициализируется при старте приоожухи и тд

В защиту ORM приведу такой кейс. На странице магазина фильтр по разным характеристикам товаров, коих десятки, все поля опциональные. Как такое на бэке обрабатывать без ORM? Как такой SQL составить? Склеивать строчки в where ... and ... and ...? Это очень error-prone

Много кто ) Но, Я так и не понял, почему оно медленнее чем SQL. Не больший контроль, не ещё что-то, а про скорость сразу говорят. Как будто ORM из всех вариантов самый неоптимальный SQL генерит