Senior Node.js Engineer в Yalantis
  • Яка мова програмування найкраща для Back-end?

    Я не погоджуюся з вами, що чисті бекендери нікому не потрібні, точніше якщо говорити про суто бекенд, то тут треба ще знати Cloud та DevOps, а не лише як код самої апки писати. На фулл-стеків наче дійсно більше вакансій, але ЗП менші ніж у «чистих бекендерів з клаудом»

  • Яка мова програмування найкраща для Back-end?

    Якщо відповідати більш-менш об’єктивно, то тут в залежності яка мова вам більше подобається, тому було б краще кожне з них по-троху спробувати, не існує найкращої мови, у кожної є свої плюси і мінуси, десь їх більше, десь менше. Якщо вподобання на даний момент не дуже принципові, то можна банально глянути на яку мову більше вакансій і рейтинг ЗП. У Node.js наприклад найбільше вакансій і досить високі рейти ЗП. Також по ідеї не помилитеся, якщо оберете Go чи C#

  • Deno помер, хай живе Deno 2

    Дякую за гарну статтю!

    Як на мене 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.

  • Витискаємо максимум перформансу з NestJS

    ну то нафіга вам було розпочинати цей тред, коли ви не можете довести свої слова?

    Підтримали: Jum Beam, Andrey
  • Відбувся реліз Deno 2.0 RC. Чи замінить він Node.js?

    Особисто я не розумію який сенс використовувати 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

  • Витискаємо максимум перформансу з NestJS

    Мені було б цікаво подивитися, якби Ви створили репозиторій і показали на практиці як це реально допомагає в покращенні перформансу HTTP серверу.
    На рахунок передачі ArrayBuffer, не забувайте, що перед передачею даних, Вам треба ці дані в ArrayBuffer спершу перетворити. Якщо про SharedArrayBuffer, то він власне shared, і треба буде з рейс кондішинами боротися. На рахунок портування обʼєктів з одного хіпу V8 у інший, раніше не чув про таке, можете, будь ласка, дати посилання?
    Щодо однієї машинерії libuv на всі воркер треди, на скільки мені відомо, там по інстансу libuv на кожен тред, ну і власне по 4 цих потоки, чи я помиляюсь? Можете, будь ласка, дати посилання щодо цього.
    На рахунок підіймання окремих серверів на воркер тредах, як Ви пропонуєте балансити навантаження між цими сереверами? Ще одним воркер тредом?

    Підтримав: Andrey
  • Витискаємо максимум перформансу з NestJS

    це не спрацює від слова взагалі, у вас перформанс зʼїсть серіалізація і десереалізація даних для передачі даних всередину воркер треду і назад, ви лиш понизите перформанс серверу таким рішенням, можете проексперементувати

  • Витискаємо максимум перформансу з NestJS

    Queue це більше для випадку коли задачу можна вирішити асинхронним способом, тобто покласти її вирішення в бекграунд, або розбити задачу на менші, щоб велика задача не блокувала івент луп.
    Пул воркерів це специфічна штука, яка спрацює лиш в залежності від ситуації, для того щоб взагалі розглядати цей варіант, треба щоб на машині на якій задеплоєний бекенд застосунок було достатньо ядер) з мого досвіду, пул воркерів може бути помічним якщо у нас є CPU intensive задача, у якої не великий input та output, бо коли ми передаємо дані між воркерами, там теж відбувається сереалізація/десереалізація, тому наприклад 0 сенсу використовувати воркери, щоб зробити в них JSON.parse() великого JSON-у

  • Витискаємо максимум перформансу з NestJS

    Напевно більша частина екосистеми Node.js не у ’системі nest libs’ і не біда) Вам нічого не заважає створити NestJS провайдер, можливо завернути його ще у модуль і додавати в NestJS DI все що завгодно) Не подобається cache-manager — інжектіть інстанс ioredis напряму і у вас буде доступ до всіх команд Redis.

    Чому це ioredis без типів? Він на typescript написаний. До речі, якщо Ви зайдете в source code nest-redis, про який згадуєте, то якраз побачите, що це дуже тонка обгортка над ioredis, і типи всі беруться напряму з ioredis 🙃

  • Витискаємо максимум перформансу з NestJS

    Дякую!

    Логування насправді досить прожерлива штука, якщо багато логів, воно сповілюнює навіть бекенди написані на Rust, що вже говорити про Node.js) Я увімкнув

    pino.destination({ sync: false })

    це наче те що потрібно, якщо не помиляюся, по посиланню на яке Ви надіслали говориться про саме обробку логів (запис у файл, надсилання на агрегатори, pino-pretty і т.д.) а не саме логування stdout в worker-thread

    На рахунок чистого Fastify, то тут вже треба сідати пробувати писати)

    По uWebSockets, можливо Ви і праві, швидше ризиків нема, ніж є, але всеодно трошки стрьомно після того як він публікував порожні релізи в npm, але так, бібліотека дійсно класна)

    Підтримав: Роман Кушин
  • Витискаємо максимум перформансу з NestJS

    Дякую, радий що Вам сподобалася стаття) так, я теж дуже люблю NestJS)

  • Витискаємо максимум перформансу з NestJS

    Не розумію про що ви говорите, в запропонованій мною версії JsonCacheInterceptor використовується голий ioredis клієнт без cache-manager, до того ж ioredis дає можливість відправляти чисті команди в Redis, розкриваючи всю його силу, чи чого ви очікували?

  • Витискаємо максимум перформансу з NestJS

    Звісно що бібліотеки призначені виключно для Express.js не сумісні з Fastify, але у 2-го теж велика екосистема і з мого досвіду завжди вдавалося знайти потрібний аналог

  • Витискаємо максимум перформансу з NestJS

    Як Ви могли бачити зі статті, бенчмарк тут досить сильно приближений до реальності з даунстрім сервісом і логуванням, а не просто дудос health ендпоінту в голому застосунку) Також є і приклади з реального досвіду на скільки зростає перформанс від деяких з кроків, тому не розумію де Ви тут побачили сферичний вакуум)

    Підтримав: Ivan Romaniv
  • macOS 15: розбираємося, що відомо про велике оновлення

    Шкода що вже стільки років Apple не додумується додати нормальний менеджмент вікон як у Windows, маю на увазі можливість компонувати вікна на екрані, зараз можна лише зробити це компонування з 2-ма вікнами, а third party апки не роблять це на стільки круто як це є у Windows

  • А ви девелопери чи «фреймворкери»? Обговорюємо!

    Тут має бути баланс між тим і іншим, якщо ти супер девелопер, але не знаєш фреймворків, то time to market твоєї апки відправиться у безкінечність, на противагу якщо ти «фреймворкер», то швидше всього ти зможеш швидко зробити 80% будь якого функціоналу, проблеми почнуться саме з тими 20% що залишилися. На мою думку цілком окей починати вивчення з фреймворків, щоб швидко могти добитися практичного результату (перший пет-проєкт, перша робота) бо початківцям дуже важливо бачити результат своєї роботи, а не, вибачте за слово, надрочувати алгоритми на структури даних і аж через 1-2 роки добратися власне до практичної роботи, цей варіант підходить хіба що, якщо ви в університеті і у вас ще є 2 вагони вільного часу. Тому, я вважаю, що цілком окей починати з фреймворків, а потім вже (в ідеалі паралельно) розширювати свої знання на алгоритми, просунутий SQL, і якісь більш глибокі знання самої мови

  • Купив український скін в World of Tanks? Отримай 12 год тюрми або довічне! На росії біснуються через збір Wargaming на реанімобілі для ЗСУ

    А що, можна робити новини тільки про ті країни які подобаються?

  • Apple випустить нові MacBook Air і iMac на M3

    Для людей яким MacBook Pro 16″ не по карману, але хочеться Макбук з людською діагоналлю екрану))

  • За яким ноутбуком працюєте?

    Ага, дякую)

  • За яким ноутбуком працюєте?

    Агааа, дуже дякую

← Сtrl 123456 Ctrl →