Интересное исследование, пару месяцев назад делал аналогичное для Node.js+Rust WASM практически для тех же задач. Главная проблема с вызовом функций из WASM это оверхед при передаче/получении аргументов и результатов функций, поэтому задачи в стиле сложить два числа выполняются Node.js быстрее. В случае с хешом, Node.js под капотом использует плюсы и тут вряд-ли что-то можно оптимизировать.
Тоже натолкнулся на такую проблему. В итоге пришлось отказаться от shared каталога, все модели респонсов/реквестов храню в backend и импортирую их во фронт. Решение не очень красивое, но рабочее
Я имел в виду немного другое.
После добавления passport и настройки его стратегий на уровне контроллера в объекте request появляется поле user с текущим пользователем, с этим все понятно.
JSDOM умеет рендерить виртуальный дом, это удобно для парсинга SPA. Но нужно дождаться, когда фронт получит все данные с бэкенда. В остальных случаях это оверхед, легко упереться в лимит по памяти.
Для таких задач я использую cheerio, он предоставляет такой же интерфейс как и jQuery. Это весьма удобно, можно тестировать экстрагирование данных в консоли браузера, а потом просто вставлять в код краулера
В обновления Node периодически включены обновления V8 с оптимизацией перфоманса, так что обновление Node в большинстве случаев дает положительный эффект.
часто наблюдаю статьи, где описывается следующая архитектура:
нода выступает в качестве фронтенд-сервера (рендерит вьюшки, собирает данные с бэкенда), а бэкенд (который был написан 5 лет назад программистом, который уже сменил работу) остается прежним
как по мне так нода самый удобный вариант из перечисленного, особенно с модулем jsdom. Все сводится к тому что просто пишешь и отлаживаешь js-код в консоли браузера, который достает нужные данные, и копипастишь его в нодовский файл
стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным
нет, для чтения файлов и других I/O операций используется ThreadPool, ответа от которого ждет непосредственно сама нода. А пока она ждет, может заняться другими вещами
Интересное исследование, пару месяцев назад делал аналогичное для Node.js+Rust WASM практически для тех же задач. Главная проблема с вызовом функций из WASM это оверхед при передаче/получении аргументов и результатов функций, поэтому задачи в стиле сложить два числа выполняются Node.js быстрее. В случае с хешом, Node.js под капотом использует плюсы и тут вряд-ли что-то можно оптимизировать.
но инжектить юзера прямо в сервис весьма удобно
После добавления passport и настройки его стратегий на уровне контроллера в объекте request появляется поле user с текущим пользователем, с этим все понятно.
Однако если в сервис заинжектить request
то this.request не будет содержать user
А случаем не сталкивались с проблемой получения текущего юзера из заинъекченного request?
Для таких задач я использую cheerio, он предоставляет такой же интерфейс как и jQuery. Это весьма удобно, можно тестировать экстрагирование данных в консоли браузера, а потом просто вставлять в код краулера
И есть ли смысл использовать JSDOM для данной задачи?
Нашел на просторах интернета
нода выступает в качестве фронтенд-сервера (рендерит вьюшки, собирает данные с бэкенда), а бэкенд (который был написан 5 лет назад программистом, который уже сменил работу) остается прежним
как по мне так нода самый удобный вариант из перечисленного, особенно с модулем jsdom. Все сводится к тому что просто пишешь и отлаживаешь js-код в консоли браузера, который достает нужные данные, и копипастишь его в нодовский файл
стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным
если, к примеру, использовать кластер для http-сервера, то запросы будут распределяться между потоками по алгоритму Round Robin
http://jade-lang.com/
https://github.com/phated/gulp-jade