Pull to refresh
8
0
Send message

Интересное исследование, пару месяцев назад делал аналогичное для Node.js+Rust WASM практически для тех же задач. Главная проблема с вызовом функций из WASM это оверхед при передаче/получении аргументов и результатов функций, поэтому задачи в стиле сложить два числа выполняются Node.js быстрее. В случае с хешом, Node.js под капотом использует плюсы и тут вряд-ли что-то можно оптимизировать.

Тоже натолкнулся на такую проблему. В итоге пришлось отказаться от shared каталога, все модели респонсов/реквестов храню в backend и импортирую их во фронт. Решение не очень красивое, но рабочее
так и сделал) не особо красиво получилось + лишнее чтение данных юзера из базы
но инжектить юзера прямо в сервис весьма удобно
Я имел в виду немного другое.
После добавления passport и настройки его стратегий на уровне контроллера в объекте request появляется поле user с текущим пользователем, с этим все понятно.

Однако если в сервис заинжектить request
@Injectable({ scope: Scope.REQUEST })
export class FooService {
  constructor(
    @Inject(REQUEST) private request: Request,
  ) {
  }
}

то this.request не будет содержать user

интересно было бы увидеть пример
Добрый день! Спасибо за обзор!
А случаем не сталкивались с проблемой получения текущего юзера из заинъекченного request?
JSDOM умеет рендерить виртуальный дом, это удобно для парсинга SPA. Но нужно дождаться, когда фронт получит все данные с бэкенда. В остальных случаях это оверхед, легко упереться в лимит по памяти.
Для таких задач я использую cheerio, он предоставляет такой же интерфейс как и jQuery. Это весьма удобно, можно тестировать экстрагирование данных в консоли браузера, а потом просто вставлять в код краулера
А почему не использовали request или got? Пункты 1 и 2 он прекрасно покрывает.
И есть ли смысл использовать JSDOM для данной задачи?
В обновления Node периодически включены обновления V8 с оптимизацией перфоманса, так что обновление Node в большинстве случаев дает положительный эффект.

Нашел на просторах интернета
А не пробовали использовать child_process для распаралеливания построения дерева?
гугл на одном из недавних выступлений сказали, что пока этого в движке V8 нет
часто наблюдаю статьи, где описывается следующая архитектура:

нода выступает в качестве фронтенд-сервера (рендерит вьюшки, собирает данные с бэкенда), а бэкенд (который был написан 5 лет назад программистом, который уже сменил работу) остается прежним
писал парсеры на .net, java, scala и на ноде

как по мне так нода самый удобный вариант из перечисленного, особенно с модулем jsdom. Все сводится к тому что просто пишешь и отлаживаешь js-код в консоли браузера, который достает нужные данные, и копипастишь его в нодовский файл

стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным
пхп не убьешь, учитывая кол-во сайтов на Drupal, Joomla и прочих CMS
никто не запрещает замутить кластер с нодой, тогда будет сколько вам угодно потоков

если, к примеру, использовать кластер для http-сервера, то запросы будут распределяться между потоками по алгоритму Round Robin
нет, для чтения файлов и других I/O операций используется ThreadPool, ответа от которого ждет непосредственно сама нода. А пока она ждет, может заняться другими вещами
это Вы написали «Духлесс»?
как этот проект связан с его оригиналом для Java и Scala, помимо названия и концепта?
1

Information

Rating
Does not participate
Registered
Activity