а в Go нит

говорити про метапрограмування*

Привет, кто-то имел опыт с динамическими соединениями к БД, в зависимости от пользователя?  В 2 словах, нужно разделить одну БД на много однотипных для каждой компании.  Не могу прийти к решению, как лучше всего определять к какой БД подключаться в момент вызова API.

о, в розетку нужен Middle NodeJS/TypeScript Backend/Fullstack Developer
я думал там ток ПХП

Потому что на го это практически нереально?)

отож

там шарпи нє?

а я взагалі хз шо там. Колись багато PHP вони брали. Ну це для самого магазину я так розумію

Чим потрібно займатися:
• Розробляти сервіси і мікросервіси на NodeJS;

мікросервіси це як сервіси тільки поменьше?

в 10^-6

всем привет, есть такой вопрос: норм ли использовать интерсепторы в nestjs в такой ситуаци:

Есть метод POST /auth/login { email, password }

тут просто вернется jwt токен и все. Но есть такой сценарий еще - если мы залогинились (создался токен), то надо еще сохранить некоторую инфу - например gaCookie сохранить в бд если она была передана, обновить кол-во раз сколько пользователь логинился и тд. Просто это прямого отношения к логину не имеет, но используется вместе. Это норм если будет:

@Post('/login')
@UseInterceptors(TrackLoginInterceptor)
async login(email, password) {
   return this.authService.login(email, password);
}

что то типа того

они усилоно от него уходят

А есть какие-нибудь примеры замены интерфейсов на чистом Джс?

Чтобы допустим был контракт, и класс ссылался на контракт, а не на реализацию

там и онгуляр под капотом

Вау, спасибо

Вопрос. Как я понимаю, правильно чтобы всякие апи-ключи хранились в переменных в отдельном .env файле, а не в коде проекта.
При этом вроде как рекомендуют .env файл добавлять в .gitignore(и он там зачастую даже по умолчанию).

Вот допустим я сделал так и запушил код проекта в удаленный репозиторий, как тогда другой разработчик из моей команды узнает все переменные и ключи, если файла .env нет в репозитории? Мне как-то отдельно ему их сообщать что ли?

Хороший вопрос. Чаще всего бросают эти файлы друг другу в каком нибудь слаке но это bad practice

Мы храним в secrets manager в aws копию (это секюрнее чем слак, типа)