👍

Добрый день вопрос по impress правильно ли можно понимать у каждого воркера свой собственный инстанс контекста домена как пример example chat и порты 8001 8002 тоесть W1 , W2 являются разными инстансами контекста. просто исходя из кода impress он для воркера использует vm.createContext который получает контекст по ссылке. Вопрос почему тогда у каждого воркера новый инстанс контекста домена

Ооо, топ

Бэк на тайпскрипте норм писать ? Nest самый топ ?

Тайпскрипт - подбитый бомбовоз

Тов. Архитектор теперь переходит в наступление.
Всё берегитесь теперь другие архитекторы которые хейтят node.js 😉

коротко и ясно, спс ))

Взагалі, якщо так подумати, дефолтні значення аргументів функції — це погана ідея.
Як мінімум тому що дефолти можуть змінюватися. І якщо вони змінюються, потрібно залазити в тіло функції і правити їх (хоча по-суті ці дефолти не мають ніякого відношення до логіки, яку виконує функція, єдине на що вони впливають — це на те, як дана функція викликається).
А у випадку, якщо я використовую одну і ту саму функцію в двох місцях, але в одній частині програми мені потрібні одні дефолтні аргументи, а в іншій частині програми потрібні інші — що в такому разі робити?  
Тому я не бачу жодної валідної причини інлайнити дефолтні значення аргументів в тіло функції. It somehow violates the Separation of Concerns Principle
Partial application looks like a better choice here

Nest топ тем, что он предлагает архитектуру

он не предлагает архитектуру, а если ты про примеры из доки то там говно

Все относительно

Выбрал нест и можно не парится о том как дизайнить прогу?

норм писать, на джс тоже норм, нест хороший ибо с коробки ДИ + адаптеры под любую инфру, фастифай хорош скоростью, ажв схемой и заменой мидлварей на хуки

До речі з типізацією мені здається така сама проблема. До слова про тайпскрипт,
Адже, по-суті, анотація типів потрібна для валідації вхідних і вихідних даних, хіба ні?
Навіщо інлайнити валідацію, до прикладу, аргументів і значень, які повертає функція, метод або конструктор, в тіло цієї самої функції, метода або конструктора, як це роблять з тайпскриптом?
Можна ж для валідації використовувати окрему бібліотеку, як це роблять до прикладу в кложурі з модулем spec
Я уже декілька тижнів над цим думаю, але досі не можу зрозуміти які є реальні переваги в тому, щоб використовувати анотацію типів?

Ми ж коли анотуємо типи, ми змішуємо бізнес логіку з валідацією даних, хіба ні? Навіщо це?

Если не париться с дизайном, то следует выбрать экспресс. Он в таком случае лучше подойдет

Это немного разные вещи. Валидируют в ТС с помощью zod, yup, io-ts, runtypes (куча либ). А сам ТС-инструмент - создан не для валидации

То есть, если неопытный инженер начнет юзать nest то это спасет его от гавнокода?

Неопытный инженер будет думать что он спасён от говнокода

Какой нест, нужно брать impress