M
Если ты имеешь ввиду в консоле редактора, то есть только референсная ошибка
Size: a a a
2021 February 02
DT
Покажи запрос постмана, как location шлешь?
R
Создал репу с мелким примером. Объясните пожалуйста что я делаю не так, почему при использовании метода из сервиса
https://github.com/revivalme/nestjs-prisma-transaction-test
$transaction работает неправильно? Не хочется пилить костыли в виде копипаста логики метода при каждом использовании $transactionhttps://github.com/revivalme/nestjs-prisma-transaction-test
неужели тут никто не использует связку NestJS + Prisma?
PL
неужели тут никто не использует связку NestJS + Prisma?
оно генерит код по бд?
R
оно генерит код по бд?
генерит бд по коду 😂
PL
M
Покажи запрос постмана, как location шлешь?
Post или Get?
VL
оно генерит код по бд?
Да
GD
Подскажите, сокеты как-то надо защищать?
GD
токены туда прокидывать jwt или ещё както?
ML
думаю удобно было бы, если бы более оптимально зависимости подгружались, ну например есть пакет A1, у него в зависимостях B1-Bn? и например пакет A2 у которого B2-и B3, и т.д. ну и типо что бы были не копии пакетов (естественно если совпадают версии)
Pnpm не оно?
2021 February 03
AZ
А можно как то подружить Нест и worker_threads?
Д
А можно как то подружить Нест и worker_threads?
смотря что реализовывать в тредах(проблемы с внедрением зависимостей как минимум), интересный вопрос конечно
AZ
Именно, что интересный ))) можно, конечно, воркеры делать на старом добром js, но эт как-то несерьёзно что ли )
AL
А можно как то подружить Нест и worker_threads?
Варианта использования я могу назвать только 2. В силу того, что DI не может происходить между тредами, использовать получается в следующих случаях:
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
NG
Варианта использования я могу назвать только 2. В силу того, что DI не может происходить между тредами, использовать получается в следующих случаях:
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
- Методу какого-нибудь сервиса нужно выполнить тяжёлую операцию и её можно вынести в tread, чтобы не нагружать основной поток. Все необходимые процессу зависимости нужное передавать туда напрямую.
- Процесс всего приложения можно запустить в нескольких потоках. Так как это потоки, входящие сообщения будут распределяться на все созданные потоки. То есть фактически будет запущено N копий приложений на N процессорах. Проблема что в реальных условиях это не эффективно. Обычно микросервисы запускаются в изолированных контейнерах (docker, pod) и толку от многопоточности не много, так как проще в управлении запустить несколько контейнеров и нагрузку будет уже регулировать nginx, ingress или другой балансировщик.
по первому
NG
говорят, что в ноде юзаются green threads
NG
т/е синхронить не надо