kk
У всех свое всегда. Потому что задачи разные и бизнес тоже.
Это конечно правда, но работаю с nest пару недель, и опыта почти нет, как итог не знаю во что выльется проект.
Size: a a a
2020 December 09
VA
У меня стандарт сейчас.
- modules
— user
—- dto
—- interceptors
—- schema
—- interfaces
- common
— interceptors
— pipes
— decorators
— user
—- dto
—- interceptors
—- schema
—- interfaces
- common
— interceptors
— pipes
— decorators
🏡K
Нам тут походу и Apollo 3 думает делать больно с кэшем... Очень надеюсь что они не будут заставлять работать на прямую с кэшем как сейчас в beta думают делать.
я акиту юзаю для кэшей, графовский не юзаю, чет перебор будет с технологиями), в идеале хочу чтобы можно было эти кэши и сабскрипшены легко потом перенести на бэк не меняя кода на фронте
VA
- modules
— user
—- dto
—- interceptors
—- schema
—- interfaces
- common
— interceptors
— pipes
— decorators
— user
—- dto
—- interceptors
—- schema
—- interfaces
- common
— interceptors
— pipes
— decorators
А лучше сразу в монорепу загнать все.
kk
У меня сейчас идёт:
— ./Modules (modules / controllers)
—-./schemas
—-./sub-services-folder?
——*service
—-*cotroller?
—-*dtos
—-*module
—-*service
— ./Modules (modules / controllers)
—-./schemas
—-./sub-services-folder?
——*service
—-*cotroller?
—-*dtos
—-*module
—-*service
VA
У меня сейчас идёт:
— ./Modules (modules / controllers)
—-./schemas
—-./sub-services-folder?
——*service
—-*cotroller?
—-*dtos
—-*module
—-*service
— ./Modules (modules / controllers)
—-./schemas
—-./sub-services-folder?
——*service
—-*cotroller?
—-*dtos
—-*module
—-*service
Я тебе говорил главную идею. Сделать так что бы я мог просто взять модуль пользователя например или товара и у меня он сразу работал на другом проекте без особых изменений (желательно вообще без них). Вот прям, пришел - нажал CTRL + C /CTRL + V и потому в app,module.ts воткнуть его в imports.
Если ты можешь это предоставить, тогда у тебя достаточно нормальная структура проекта.
Если ты можешь это предоставить, тогда у тебя достаточно нормальная структура проекта.
kk
Текущий модуль пользователя я думаю вынести в либу именно по этой причине, включая авторизацию которая идёт в одном с пользователем модуле.
kk
Ибо сейчас все контроллеры подключают пользователя как модуль из директории src, они не могут с ним работать как с пакетом, а хотелось бы, остальное уже хорошо, за исключением того что сейчас схема пользователя привязана к монге.
🏡K
пользователь может отличатся на разных проектах, где-то инн поле есть, гдето да база пг, где то монга
🏡K
делать нужно чтобы хоть куда мог скопировать и вставить
🏡K
ну это все идеальный вариант, если нужно мвп, то и делай как хочешь главное чтобы работало, птом исправишь когда задачи кончатся) или уволишся и другой разраб все перепишет после тебя
kk
поправочка, Контроллеры подключают отдельные сервисы пользователя.
VA
ну это все идеальный вариант, если нужно мвп, то и делай как хочешь главное чтобы работало, птом исправишь когда задачи кончатся) или уволишся и другой разраб все перепишет после тебя
:D ;D нормальный совет :D :D А потом мы придем и будем страдать. Хотя это и так всегда так получается.
kk
ну это все идеальный вариант, если нужно мвп, то и делай как хочешь главное чтобы работало, птом исправишь когда задачи кончатся) или уволишся и другой разраб все перепишет после тебя
Вот так счастье писать такой код и не мучатся после этого)
🏡K
когда сильно декомпозируешь то тестировать меньше кейсов и мест для слома меньше, и код чище, можно один раз писать и забывать, даже потом когда я возвращаюсь к такому коду через 2 года, сразу понимаю что и где, а в петы где мвп каша когда через неделю прихожу то нихрена не понимаю как оно так работает, ну мое мнение
AZ
у меня так
apps/backend - монолит бэка
apps/frontend - монолит фронта
apps/mobile - монолит мобилы - пустая папка :)
apps/mail-sender-ms - мs
apps/auth-ms - мs
apps/auth-client - вебпак5 федерация микрофронтенд, начинаю только тыкать, название пока такое
libs/mail-sender/server - либа бэка
libs/auth/server - либа для бэка
libs/auth/client - либа для фронта с логикой
libs/auth/material - либа для фронта с гуи
libs/auth/common - либа общая
libs/auth/flutter - либа для мобилы - начинал тестово
apps/backend - монолит бэка
apps/frontend - монолит фронта
apps/mobile - монолит мобилы - пустая папка :)
apps/mail-sender-ms - мs
apps/auth-ms - мs
apps/auth-client - вебпак5 федерация микрофронтенд, начинаю только тыкать, название пока такое
libs/mail-sender/server - либа бэка
libs/auth/server - либа для бэка
libs/auth/client - либа для фронта с логикой
libs/auth/material - либа для фронта с гуи
libs/auth/common - либа общая
libs/auth/flutter - либа для мобилы - начинал тестово
у вас на докере?
🏡K
вначале сложно делить сильно на куски, потом привыкаешь, на работе вот так не делим, трудно между таким и таким кодом переключатся, по разному думаешь)
kk
когда сильно декомпозируешь то тестировать меньше кейсов и мест для слома меньше, и код чище, можно один раз писать и забывать, даже потом когда я возвращаюсь к такому коду через 2 года, сразу понимаю что и где, а в петы где мвп каша когда через неделю прихожу то нихрена не понимаю как оно так работает, ну мое мнение
Так а я о чём? Я морально не могу хреново к этому подходить.
🏡K
у вас на докере?
кубер, дома кубер и на работе кубер, доккер только для дев режима и там и там
kk
А разве кубер это не инструмент для работы с множеством докеров?