Nest JS производительность создания объекта - PullRequest
Новая
       5

Nest JS производительность создания объекта

1 голос
/ 05 марта 2020

в гнезде JS, можно определить область инъекции инъецируемых объектов. (возможны: singleton, request, transient)

в do c рекомендуется всегда использовать singleton области действия везде, где это возможно, так как область действия запроса будет создавать гнездо для каждого поставщика на каждом Цикл запроса-ответа, который может повлиять на производительность приложения

Использование поставщиков с областью запроса повлияет на производительность приложения. Хотя Nest пытается кэшировать как можно больше метаданных, ему все равно придется создавать экземпляр вашего класса при каждом запросе. Следовательно, это замедлит ваше среднее время отклика и общий результат тестирования. Если поставщик не должен быть ограничен запросами, настоятельно рекомендуется использовать одноэлементную область по умолчанию.

С каких пор создание объектов потребляет так много ресурсов? что вся структура построена вокруг одноэлементных экземпляров, что делает эти экземпляры «заполненными состоянием» в том смысле, что я не могу безопасно использовать «переменную экземпляра», не опасаясь, что 2 запроса / потребителя могут использовать один и тот же экземпляр поставщика одновременно (из-за асинхронной c природы узла) и конфликтующих друг с другом переменных экземпляра?

вот что я пытаюсь сделать: 

export class MyClass {
 constructor (...some dependencies) {

 }

 someMethod(payload){
  this.myInstanceVariable = payload.data;
  someMethod2();
 }

 someMethod2(){
  // this.myInstanceVaraible usage, which i cant really trust it contains what i expect it to
 }
}

Я пришел из ruby фон. когда я писал службы в ruby, каждый запрос создавал бы экземпляры тех служб, в которых он нуждался, и после выполнения запроса все эти объекты автоматически собирались мусором. таким образом, я мог бы безопасно определять переменные экземпляра в моих сервисах - не заботясь о «конфликтах экземпляров».

...