Size: a a a

NestJS — русскоязычное сообщество

2021 February 03

NG

Nick Galko in NestJS — русскоязычное сообщество
хотя может взрослую многопоточность завезли
источник

NG

Nick Galko in NestJS — русскоязычное сообщество
источник

NG

Nick Galko in NestJS — русскоязычное сообщество
ща доку посмотрю
источник

NG

Nick Galko in NestJS — русскоязычное сообщество
Anton Larichev
Варианта использования я могу назвать только 2. В силу того, что DI не может происходить между тредами, использовать получается в следующих случаях:
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
мне скорее интересно - кто-нибудь всякие threadpool и другие модели реализовывал ли на ноде
источник

NG

Nick Galko in NestJS — русскоязычное сообщество
не сколько для практики - сколько хотел бы на числа посмотреть
источник

KB

Konstantin Belkin in NestJS — русскоязычное сообщество
Всем привет, кто подскажет с точки зрения архитектуры приложения на микросервисах с grpc, на сколько правильнее их разбивать? На более мелкие типа сервис поиска/комментариев/постов и тд или же лучше объединить в более крупные сервисы?
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
Столкнулся с интересной особенностью. Есть вот такая DTO, которая предполагает что  поля - опциональные для ввода, но у них есть дефолтное значение.

При этом у меня включен самый строгий режим в TypeScript. И когда я передаю username в функцию, которая ожидает строку, TS ругается, что там может быть ещё и undefined.

Как решить эту проблему?
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
Konstantin Belkin
Всем привет, кто подскажет с точки зрения архитектуры приложения на микросервисах с grpc, на сколько правильнее их разбивать? На более мелкие типа сервис поиска/комментариев/постов и тд или же лучше объединить в более крупные сервисы?
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
источник

🏡К

🏡 Назар Калитюк... in NestJS — русскоязычное сообщество
мне кажеться, или String(undefined) === “undefined”?
источник

VA

Veaceslav Artiom in NestJS — русскоязычное сообщество
Dilame 🎩 Bowzee ⠀⠀⠀ོ ⠀⠀
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
+++
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
🏡 Назар Калитюк
мне кажеться, или String(undefined) === “undefined”?
Тем не менее, это string. У меня вопрос немного в другом
источник

🏡К

🏡 Назар Калитюк... in NestJS — русскоязычное сообщество
Dilame 🎩 Bowzee ⠀⠀⠀ོ ⠀⠀
Столкнулся с интересной особенностью. Есть вот такая DTO, которая предполагает что  поля - опциональные для ввода, но у них есть дефолтное значение.

При этом у меня включен самый строгий режим в TypeScript. И когда я передаю username в функцию, которая ожидает строку, TS ругается, что там может быть ещё и undefined.

Как решить эту проблему?
сделать if (name !== undefined) {func(name)}
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
🏡 Назар Калитюк
сделать if (name !== undefined) {func(name)}
Но эта проверка излишняя по своей природе. И засоряет код, ведь это не единичный случай
источник

KB

Konstantin Belkin in NestJS — русскоязычное сообщество
Dilame 🎩 Bowzee ⠀⠀⠀ོ ⠀⠀
Микросервисы - как очки, вы почувствуете, когда они вам станут нужны. Судя по вашему вопросу, вы этого не чувствуете. Поэтому пока что лучше объединить все ваши микросервисы в один крупный сервис. Серьёзно.
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
источник

D

Dmitriy in NestJS — русскоязычное сообщество
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Ну так и дели постепенно, когда будет необходимость
источник

D

Dmitriy in NestJS — русскоязычное сообщество
Преждевременная оптимизация - корень всех зол
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Да, и это самая типичная ошибка. Начинать разработку с микросервисов из-за планов на будущее. В итоге захлебнётесь в архитектуре раньше, чем успеете вырасти. Проверено на опыте неоднократно.
источник

S

Susa in NestJS — русскоязычное сообщество
Macos new version
источник

DB

Dilame 🎩 Bowzee ⠀⠀⠀ོ... in NestJS — русскоязычное сообщество
Konstantin Belkin
Начал изначально с такой архитектуры, так как есть некие планы на будущее где будет работа с большим количеством данных, и множеством не связанных с собой бизнес логикой приложениями
Изучите подход monorepo
источник

KB

Konstantin Belkin in NestJS — русскоязычное сообщество
Dilame 🎩 Bowzee ⠀⠀⠀ོ ⠀⠀
Изучите подход monorepo
У меня микросервисы на этом подходе написаны)
источник