зачем разные группы endpoint'ов в разных пакетах?! да, оно красиво выглядит в файловой системе, но не забываем что в Go пакет это папка
Увидел ролик про архитектуру https://www.youtube.com/live/0Fhsgmz-Gig?si=S_F7F6G2HkdqN3zc С 6 минуты, про плохой и хороший пакет
у видео есть гит репозиторий с кодом?
я не нашел, к сожалению
да это плохой пакет. Но он говорит, что разные реализации репозиториев в одном пакете плохо. Типо монга и пг в одном пакете плохо - это так. То, что у тебя разные эндпоинты в одном пакете - это ок вполне
то есть нет смысла к примеру делить в моем случае разных провайдеров в разные пакеты? auth/ provider/ email/ handlers.go email.go vk/ handlers.go vk.go provider.go service.go func NewService(emailProvider *email.Provider, vkProvider *vk.Provider) (*Service, error) { if emailProvider == nil { return nil, ErrNoEmailProvider } if vkProvider == nil { return nil, ErrNoVKProvider } return &Service{ emailProvider: emailProvider, vkProvider: vkProvider, }, nil }
if vkProvider == nil { return nil, ErrNoVKProvider } мне кажется это лишнее NewService не должна возвращать ошибки, ибо там нет ошибки. Мы ожидаем что пользователь фунцкии не передаст nil В худшем случае можно панику кинуть, ибо это не ошибка а ошибка программиста
ИМО, в принципе делать один сервис, в который передаются несколько провайдеров, неправильно. Сейчас их два, а когда появится еще десяток? На каждый провайдер нужен отдельный конкретный сервис, который будет создаваться в зависимости от инпута.
А норм делить?
провайдеры, да. Один провайдер - один пакет
а что внутри этих провайдеров происходит?
по сути описаны хендлеры
сделай это все в одном пакете, мы про это писали
https://paste.gg/p/anonymous/a7ff904c2128427f965dc406264090fe ну типа того допустим выглядит handler для вк)
Обсуждают сегодня