Ребят, помогите советом плс. Есть два приложения, одно из них считывает очень большой файл и через эмит разных событий передает данные по сокетам на другое приложение, которое должно собирать данные в таблицы и записывать в бд. Стрим читается очень быстро, второе приложение не может справиться с такой нагрузкой (за пару мин десятки тысяч строк отправляется) из-за этого на первом приложении утечка памяти. Какие есть варианты решения? Сделать искусственную задержку в стриме чтения файла (звучит уже ужасно) или дело в другом приложении и нужно его оптимизировать?
Второе приложение на си-шарпе. Вместо другого приложения я локально делал сокет сервер на ноде и записывал данные в файл, утечек нет, нода с записью в файл справляется, эксперимент так себе получился :)

Спасибо, изучу)

всем привет, возможно ли реализовать алгоритм хафмана на node js?

Думаю так. В тебе виникла проблема?

просто така ідея виникла, ніколи на js не писав

На любом тьюринг полном языке можно написать любую вычислимую функцию ( алгоритм хаффмана это вычислимая функция )

а node.js тут вообще ни при чем, это не язык

Node js это среда исполнения js, а не сам язык

Він же і нічого не казав про мову, просто цікавила можливість використання node.js для його цілей

этотпримерно как рассуждать о возможности применения асфальта для перемещения 5 кг клубники с 50° на 55° северной широты

Народ, таке питання - шо скажете про Fastify, як про фреймворк для REST API ?

Більше цікавить його зручнісь і наскільки він гнучкий

Норм, но сначала нужно написать API, а уже потом выбирать фреймворк

Добрый день!
Нужен совет. У меня открыт сервер. Он при запросе на /payment отдаёт страницу, которая билдится ejs-ом. Это страница оплаты.

После успешной оплаты я хочу уведомить об этом сервер. Как сделать это безопасно?
То есть, чтобы этот запрос отправлялся только после реальной оплаты и его нельзя было сфабриковать.

Спасибо

Якщо ви купились на цифри бенчмарків чи розмови про те, що він дуже швидкий, то тут не все так просто.
У всьому іншому - мені nest більше сподобався.
*доказів не буде*

Уважаемые знатоки, сориентируйте, кто в курсе, будьте добры!

Для NestJS использовать роутинг внутри контроллера – это норма (например, декоратор @Get())?

Посмотрел воркшоп одного "девелопер адвоката" на ng-conf по NestJS, и как-то это больно выглядело, на мой взгляд: уже упомянутая высокая (концептуально) сцепленность кода в контроллере + всё те же цепочки обязанностей aka миддлвары, дифференцированные по категориям a la Angular на интерсепторы, гарды и собственно миддлвары.

Это считается нормальным подходом в нестовских кругах? Или мне попался не самый лучший докладчик?

Чем вам нравится/не нравится нест (учитывая, что все мы знаем и понимаем, что любой фреймворк – это г***о)?

а чем тебя смущает роутинг в декораторах?

Как по мне, то декораторам рядом с бизнес-логикой делать нечего.

Вызывает внутреннее неприятие :) Если серьезно, то как-то привык, что в слоеной архитектуре роутинг (или диспатчер, как угодно) – это отдельный от контроллера слой