Якщо відповідати більш-менш об’єктивно, то тут в залежності яка мова вам більше подобається, тому було б краще кожне з них по-троху спробувати, не існує найкращої мови, у кожної є свої плюси і мінуси, десь їх більше, десь менше. Якщо вподобання на даний момент не дуже принципові, то можна банально глянути на яку мову більше вакансій і рейтинг ЗП. У Node.js наприклад найбільше вакансій і досить високі рейти ЗП. Також по ідеї не помилитеся, якщо оберете Go чи C#
Дякую за гарну статтю!
Як на мене Deno зробили дуже правильні кроки з цією версією, але особисто я сумніваюся, що колись Deno чи Bun доженуть Node.js, от нема у них кіллер фіч поки + Node.js переймає їх фічі як от permission management (хоча як на мене користь від цієї фічі сумнівна), але конкуренція це дуже добре, вони змусили мейнтейнерів Node.js зарухатися і зайнятися питанням перформансу, наприклад, а також іншими фічами.
От мене завжди цікавило, чому всі так часто говорять про той std? При тому що набір нативних Node.js модулів фактично має весь функціонал, що декларується в тому ж std, наприклад node:test, node:assert, node:utils і т.д. іноді складається враження, що блог/патч ноути Node.js люди не читають на відміну від Deno та Bun. Те саме питання до нативної підтримки Typescript, це ж більше мінус, а ніж плюс, бо з певною версією рантайму буде вшита певна версія Typescript і це не можна буде менеджети окремо, якщо вже хочеться, щоб типи перевіряла лише IDE і щоб апка стартувала максимально швидко, то можна просто компілювати Typescript через SWC.
ну то нафіга вам було розпочинати цей тред, коли ви не можете довести свої слова?
Особисто я не розумію який сенс використовувати Deno чи Bun замість Node.js, ці технології для мене це якийсь популізм. Типу часто коли розказують про Deno чи Bun там розповідають:
«ооо, а знаєте що? У нас є:
1. Native API permission management (явний дозвіл доступу до файлової системи, мережі і т.д.)
2. STD
3. Нативна підтрика Typescript
4. Нативний Watch mode
5. Нативний dotenv
6. Single file executable
7. Перформанс!!!
8. Нативний форматтер
9. Нативний лінтер
»
Але прикол в тому, що всі ці люди схоже не читають блог і патч ноути Node.js, бо:
— у Node.js є підтримка 1,4,5,6 пунктів.
— STD теж фактично є якщо взяти все що є в нативних модулях Node.js (node:)
— Нативна підтримка TS, це як на мене швидше мінус ніж плюс, бо з певною конкретною версією рантайму буде йти конкретна версія TS, тобто не вийде менеджити версію TS окремо від версії рантайму.
— Ще щодо permissions API взагалі не розумію який сенс цієї фічі, якщо ваша апка це не скрипт на один файл, чи якісь примітивні круди, а повноцінний бекенд, вам швидше всього знадобиться вмикати всі пермішени, і виграшу виходить аж 0 від цієї фічі. Якби ці пермішени налаштовувалися на кожну лібу окремо це інша справа, але вони налаштовуються на всю апку.
— Щодо перформансу, насправді якщо використовувати правильні залежності, по типу Fastify, fastify-uws, чи Hono, а не слідувати Express.js карго-культу то перформанс Node.js не буде поступатися задекларованим цифрам Bun та Deno.
— 8, 9 щось у мене сумніви, що ці нативні рішення хоча б наздоганяють функціонал і екосистему ESLint та Prettier.
Виправте, може щось не шарю за кіллер фічі Deno та Bun, бо поки мені здається, що функціонал і якість імплементації цього самого функціоналу ідентичний, або поступється Node.js
Мені було б цікаво подивитися, якби Ви створили репозиторій і показали на практиці як це реально допомагає в покращенні перформансу HTTP серверу.
На рахунок передачі ArrayBuffer, не забувайте, що перед передачею даних, Вам треба ці дані в ArrayBuffer спершу перетворити. Якщо про SharedArrayBuffer, то він власне shared, і треба буде з рейс кондішинами боротися. На рахунок портування обʼєктів з одного хіпу V8 у інший, раніше не чув про таке, можете, будь ласка, дати посилання?
Щодо однієї машинерії libuv на всі воркер треди, на скільки мені відомо, там по інстансу libuv на кожен тред, ну і власне по 4 цих потоки, чи я помиляюсь? Можете, будь ласка, дати посилання щодо цього.
На рахунок підіймання окремих серверів на воркер тредах, як Ви пропонуєте балансити навантаження між цими сереверами? Ще одним воркер тредом?
це не спрацює від слова взагалі, у вас перформанс зʼїсть серіалізація і десереалізація даних для передачі даних всередину воркер треду і назад, ви лиш понизите перформанс серверу таким рішенням, можете проексперементувати
Queue це більше для випадку коли задачу можна вирішити асинхронним способом, тобто покласти її вирішення в бекграунд, або розбити задачу на менші, щоб велика задача не блокувала івент луп.
Пул воркерів це специфічна штука, яка спрацює лиш в залежності від ситуації, для того щоб взагалі розглядати цей варіант, треба щоб на машині на якій задеплоєний бекенд застосунок було достатньо ядер) з мого досвіду, пул воркерів може бути помічним якщо у нас є CPU intensive задача, у якої не великий input та output, бо коли ми передаємо дані між воркерами, там теж відбувається сереалізація/десереалізація, тому наприклад 0 сенсу використовувати воркери, щоб зробити в них JSON.parse() великого JSON-у
Напевно більша частина екосистеми Node.js не у ’системі nest libs’ і не біда) Вам нічого не заважає створити NestJS провайдер, можливо завернути його ще у модуль і додавати в NestJS DI все що завгодно) Не подобається cache-manager — інжектіть інстанс ioredis напряму і у вас буде доступ до всіх команд Redis.
Чому це ioredis без типів? Він на typescript написаний. До речі, якщо Ви зайдете в source code nest-redis, про який згадуєте, то якраз побачите, що це дуже тонка обгортка над ioredis, і типи всі беруться напряму з ioredis 🙃
Дякую!
Логування насправді досить прожерлива штука, якщо багато логів, воно сповілюнює навіть бекенди написані на Rust, що вже говорити про Node.js) Я увімкнув
pino.destination({ sync: false })
це наче те що потрібно, якщо не помиляюся, по посиланню на яке Ви надіслали говориться про саме обробку логів (запис у файл, надсилання на агрегатори, pino-pretty і т.д.) а не саме логування stdout в worker-thread
На рахунок чистого Fastify, то тут вже треба сідати пробувати писати)
По uWebSockets, можливо Ви і праві, швидше ризиків нема, ніж є, але всеодно трошки стрьомно після того як він публікував порожні релізи в npm, але так, бібліотека дійсно класна)
Дякую, радий що Вам сподобалася стаття) так, я теж дуже люблю NestJS)
Не розумію про що ви говорите, в запропонованій мною версії JsonCacheInterceptor використовується голий ioredis клієнт без cache-manager, до того ж ioredis дає можливість відправляти чисті команди в Redis, розкриваючи всю його силу, чи чого ви очікували?
Звісно що бібліотеки призначені виключно для Express.js не сумісні з Fastify, але у
Як Ви могли бачити зі статті, бенчмарк тут досить сильно приближений до реальності з даунстрім сервісом і логуванням, а не просто дудос health ендпоінту в голому застосунку) Також є і приклади з реального досвіду на скільки зростає перформанс від деяких з кроків, тому не розумію де Ви тут побачили сферичний вакуум)
Шкода що вже стільки років Apple не додумується додати нормальний менеджмент вікон як у Windows, маю на увазі можливість компонувати вікна на екрані, зараз можна лише зробити це компонування з
Тут має бути баланс між тим і іншим, якщо ти супер девелопер, але не знаєш фреймворків, то time to market твоєї апки відправиться у безкінечність, на противагу якщо ти «фреймворкер», то швидше всього ти зможеш швидко зробити 80% будь якого функціоналу, проблеми почнуться саме з тими 20% що залишилися. На мою думку цілком окей починати вивчення з фреймворків, щоб швидко могти добитися практичного результату (перший пет-проєкт, перша робота) бо початківцям дуже важливо бачити результат своєї роботи, а не, вибачте за слово, надрочувати алгоритми на структури даних і аж через
А що, можна робити новини тільки про ті країни які подобаються?
Для людей яким MacBook Pro 16″ не по карману, але хочеться Макбук з людською діагоналлю екрану))
Ага, дякую)
Агааа, дуже дякую
Я не погоджуюся з вами, що чисті бекендери нікому не потрібні, точніше якщо говорити про суто бекенд, то тут треба ще знати Cloud та DevOps, а не лише як код самої апки писати. На фулл-стеків наче дійсно більше вакансій, але ЗП менші ніж у «чистих бекендерів з клаудом»