/
ну интерфейс с БД был бы в auth.go, где эта абстракция и нужна, в store/psql лежала бы просто реализация
спасибо
Size: a a a
2020 April 24
OK
пакеты совсем независимы, все круто, все по коробочкам лежит, соединяются в одном месте - в месте передачи реализации в auth
C
ну интерфейс с БД был бы в auth.go, где эта абстракция и нужна, в store/psql лежала бы просто реализация
Если эта абстракция нужна много где
OK
Тянуть интерфейс из auth?
да нет, не нужно. зачем тебе тянуть абстракцию, которая нудна для auth в какой-то billing? billing должен сам определять то, что нужно ему
OK
имх, экспортить интерфейсы - странно, разве что для проверки реализации, что удовляетворяет интерфейсу
тип
package postgres
var _ authAuthStore = (*PostgresStore)(nil)
type PostgresStore struct {}
тип
package postgres
var _ authAuthStore = (*PostgresStore)(nil)
type PostgresStore struct {}
C
да нет, не нужно. зачем тебе тянуть абстракцию, которая нудна для auth в какой-то billing? billing должен сам определять то, что нужно ему
Ок, идея ясна
/
да нет, не нужно. зачем тебе тянуть абстракцию, которая нудна для auth в какой-то billing? billing должен сам определять то, что нужно ему
вы хотите сказать что не нужно реализовывать весь интерфейс store, а лишь его части только там где это действительно нужно.
А где-то где вызывается вся эта история уже сконфигурировать все по мере необходимости?
А где-то где вызывается вся эта история уже сконфигурировать все по мере необходимости?
OK
Тянуть интерфейс из auth?
если ты такое делаешь-видишь, то у тебя абстракция чуть растеклась, эт не страшно, ведь работает,но компоненты начинают быть связанными и это не всегда долгосрочно
(представь auth начнет зависить от billing, тип проверить, пользователь оплатил что-то или нет, и всё, попал, циклическая зависимость в го запрещена, а так были бы разные интерфейсы и не было бы проблемок)
(представь auth начнет зависить от billing, тип проверить, пользователь оплатил что-то или нет, и всё, попал, циклическая зависимость в го запрещена, а так были бы разные интерфейсы и не было бы проблемок)
OK
/dev/null
вы хотите сказать что не нужно реализовывать весь интерфейс store, а лишь его части только там где это действительно нужно.
А где-то где вызывается вся эта история уже сконфигурировать все по мере необходимости?
А где-то где вызывается вся эта история уже сконфигурировать все по мере необходимости?
именно
/
именно
ок, с этой стороны я пытался заходить, но как-то не пошло, нужно еще раз попробовать.
спасибо за совет
спасибо за совет
OK
auth определяет свой Store { GetUser, AddUser}
billing определяет свой Store { AddMoney, HaveMoney }
и оба эти интерфейса могут быть(а могут и нет) реализованы в пакете store для одной структуруы PostgresStore
billing определяет свой Store { AddMoney, HaveMoney }
и оба эти интерфейса могут быть(а могут и нет) реализованы в пакете store для одной структуруы PostgresStore
OK
в итоге auth & billing ничего не знают, что в них передают и как (сегодня постгрес, завтра монго, а послезавтра какой-то там mock). они просто хотят тот интерфейс, который им нужен
OK
копипастить такие модули в другие проекты или выносить в сервисы - просто песня)
/
копипастить такие модули в другие проекты или выносить в сервисы - просто песня)
это главное)
RS
я бы рекомендовал для долгоживущего кэша использовать более специализированные решения, которые работают вне gc, типа https://github.com/coocood/freecache
а как насчёт https://github.com/dgraph-io/ristretto?
OK
а как насчёт https://github.com/dgraph-io/ristretto?
а тож самое - сериализовать надо будет. + там eventual consistency, надо знать
RS
а тож самое - сериализовать надо будет. + там eventual consistency, надо знать
synchronize всмсл?
OK
synchronize всмсл?
в смысле, что там аммортизация при удалении как помню