Про библиотеки, дизайн кода, паттерны, стабильность, дебагинг, работоспособность std либы и так далее, я уже писал и буду писать, сейчас я хочу рассказать о конкретных проблемах, которые уже самой Node.js очень тяжело решить

Application footprint

Приложение на Node.js спокойно съедает 250-500 мб и выше оперативы (и это просто на само приложение, без каких-либо доп аллокаций), поднимается до нескольких минут и также медленно опускается.

Главное преимущество распределенной архитектуры – возможность горизонтального масштабирования, когда мы можем говорить о сотнях инстансов сервисов, но 100 инстансов на Node.js это 30-50 Gb RAM.

Да, несомненно, железо сейчас дешевое, но блять, такое же приложение на Go, будет жрать 10-50 mb оперативы, а значит 100 инстансов это 5 Gb RAM и это всего парочка супердешевых тачек.

Deploy time

Когда у вас 1 монолит или 3-4 сервиса по 2-3 инстанса вы не заметите сколько времени займет деплой новой версии приложения.

Но когда у вас 20+ сервисов по 5-7 инстансов каждого из них, тут время старта системы может оооочень сильно растянуться.

Бывает, что приходится ждать целый час пока они поднимуться, почему? Потому куберу надо скачать новый гигабайтовых образ и выделить тачку с достаточным RAM + время старта Node.js приложения очень долгое.

(отсутпление: да, мы используем partial deploy, когда катяться только изменившиеся сервисы, но когда было изменение shared lib это начинает касаться всех, а такое часто происходит)

И ты весь этот битый час сидишь и ждешь, чтобы потом проверить метрики и пойти заниматься своими задачами.

Go стартанет практически моментально при этом можно всегда держать пару пустых легких тачек, чтобы новые сервисы падали на них, а тачки, на которых сейчас приложения как раз таки оставаались пустыми для следующего деплоя.

Event Loop

Перегрузить Node.js процессы очень просто, причем без всяких сложных операций в CPU или Memory. На 800 коннектов от RMQ мы спокойно наблюдаем event loop lag в 250 мс, а это просто жопа.

(отступление: это может быть лично нашей проблемой с RMQ, amqplib или еще чем-то, но мы пользуемся прям самыми стандартными методами, на каждой отдельной очередь 1 RPS и внутри бизнес-логики только 10 IO вызовов)

А представьте что у вас 5000-10000 устройств (и это только начало) и у каждого по очереди, теперь посчитайте что да как.

Go, на моей практике, в один инстанс держал десятки тысячь коннектов и никто ниочем не задываллся (а на самом деле он может и сотни тысячь)

CI/CD

Время сборки образа и его размер измеряется десятками минут и гигабайтами веса, прохождения jest тестов может занимать до 6 Гб памяти (и это просто их issue) и почти час времени (ну будет у runner столько ресурсов, чтобы тесты всех сервисов запустить в параллель)

Встроенный в Go тесты делают тоже самое в мнгновение ока.

Тут может быть еще куча других пунктов, но вот это прям база, когда мы без вкусовщины упираемся в предел Node.js и для того, чтобы выйти за него придется потратить намного больше сил, чем например начать писать новые и аккуратно рефаторить старые сервисы, используя Go (ну или вообще с него начинать)

P.S.

Случайно наткнулся на видео как раз об этом, но в сравнении с Java.

Первый тест четко показывает картину, которую можно наблюдать при сравнении Go с Java / C# / Node.js

А во втором тесте он удивляется почему вдруг Go начал взлетать по CPU, но просто потому что допустил суперпростую ошибку (видимо, он раньше не писал на Go), которую я нашел просто посмотрев на исполняющуюся функцию и ее исправление – это добавление ровно 1 строчки кода.

Пишите на пхп и не будете никогда задаваться такими вопросами!

Иди напиши это в чат Раста

Не, мне и в моём огороде хорошо

Мне нравится что скорость твоей реакции как у бота)))

это чатгпт + мой акк в тг, всё обучено на выпусках квн 90х годов

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

Для начала поакуратнее с выражениями, ты конкретно сейчас сказал, что у меня руки из жопы, за такое бан

Переформулируй в менее агрессивном тоне

Это ты сказал )Там на тебя ничего не указывало)

То есть, я рассказываю про свой конкретный опыт с текущего проекта и ты говоришь, что у тех у кого так у них руки из жопы и это меня не касается?

Это про то когда такое случится может

Еще раз: переформулируй в менее агрессивном тоне, пожалуйста

Не вопрос) ща сек

По первому пункту я специально уточнил: \"но мы пользуемся прям самыми стандартными методами\" – возможно, я криво сформулировал, но у нас минимум зависимостей, даже фото приложу (фото 1)

Про шатдаун: да, несомненно у нас есть gracefull-shutdown который дообработает HTTP запросы и RMQ подписки и только потом закроется

Но оверхед самого закрытия IO очень большой по метрикам

А что по весу папки нод модулей?

Про гигабайтные докер образы я вообще не шучу (такую-же картину можно увидеть на странице их докера)

Да, можно взять alpine и самому туда установить что нужно, но в итоге выигрышь бывает не сравним с 5 mb Golang

Если ты про вес, то ответил в предыдущем сообщении с фоткой оригинального веса контейнеров ноды

тоже чутка накину. интересен твой опыт, делюсь своим

nest.js 30+ модулей также ~200мб на старте (а это оч жирное приложение, но с lazy модулями)
стартует не милисекунды конечно, но вполне сносно укладываемся в 3-5сек на старт (тут нест - жир из всего, но есть lazy modules, без них офк хуже было бы)
у нас модульный монолит, некоторые модули умеют стартавать отдельно, скейлить достаточно просто, когда нужно
образ bullseye-slim/bookworm-slim + пачка зависимостей ~100/~300mb + обмазались кешами и все быстро грузится на ecs. Канарейки катаются за пару минут

jest уже давно показывает плохо себя с нодой (Error в jest свой, можно прикольно поесть говна)), vitest гоняет тесты за милисекунды (даже с nest’ом) и жрет сильно меньше (замыкания в v8 оч дорогие, а jest там еще и в свою среду на каждый чих срет - оперативки на него не наберешься))

Эвент луп конечно вносит свою сложность в оптимизации и вот как пример с кучей коннекшенов - тут да, когда 5к коннектов держится, то все будет ощутимо лагать 250ms - не предел :D, нода вполне реально тут мала (хотя скорее всего есть еще простор для творчества и оптимизаций - раз такие нагрузки, то и у бизнеса деньги на это найти можно)).
go конечно действительно может из коробки столько держать (на самом деле не только go, но и любой рантайм полегче, чем нодовский), но тут я снова тоже самое про выразительные способности go 😄

Ща я даже еще раз соберу наши образы, чтобы проверить не спиздел ли я

У нас сейчас центром мира является RMQ, но до этого была Kafka и в обоих ситуациях подписки / пуллинг, жрали очень много времени при старте приложения

Еще мы обмазаны метриками и логами, что в Node.js отжирает прилично, но без этого сервисы с новыми фичами не выкатываем (потом уже можно отключить, но я про запуск как раз с новыми фичами)

"3-5сек на старт" – тут как я говорил надо учитывать еще время, которое требуется оркестратору и из-за жироты образов и потребления RAM само приложение может стартовать за это время, но все вместе складывается в минуты

Да, у нас тоже несколько модульных монолитов (приложения разделены по нагрузке или назначению, но шерят общую кодовую базе)

bullseye-slim/bookworm-slim – посмотримс, благодарю)

Про jest – понимаю что можно поменять (мы вообще пробуем на bun их проогонку мигрировать, но пока без успеха), но (1) уже на нем дохера всего написано, (2) как же заебало, что в такой обязательной вещи как тесты приходится в очередной раз натыкаться на любимое JS-вское "ах да, при нагрузке это гавно работать не будет, бери другое гавно" 😢

У нас уже на 800 очередей при 10 IO запросах 250 мс... При том что мы прям оптимизировали с профайлером, там просто практически неизбежный факт, есть решение, но придется прям мигрировать на что-то другое потому что Node.js плохо не способен вытянут 8000 IO RPS (сумарно абсолютно все запросы от и к инстансу)? Сириусли? Прям грустно

Ну, про твоя любовь к Go я уже понял, это да))

Да, несомненно надо сказать: переход на Go в данной ситуации – это один из вариантов

Есть много других языков, которые тоже дадут нужный прирост в сравнении с Node.js

Не , я про оо сколько папка с зависимостями весит ( сколько еще внутри натянуло то что у тебя в package.json )

У меня очереди небольшие как раз и отлично справляется штатный Bull.js. Тут как раз интересно тебя читать с такими проблемами :D Еще немного SQS трогали (но в основном все на булле).

У меня было много коннешенов по сокетам. Скакали на более жирные инстансы уже несколько раз. Тут у ноды все не плохо. Но опять же требуется расти в балансе в тч по мощности железа, не только горизонтально.

Есть еще тяжелый процессинг, как раз который вот в соседний сервис на раст увозили.

Так, тут ты оказался прав: у нас на 1 Gb приходится 600 мб абсолютно бесполезного дерьма (это даже не зависимости)

Пойду общаться с devops что это такое и зачем, я даже не заметил как это там появилось

Еще попробую bullseye-slim/bookworm-slim и скажу к чему пришли

Если мы хотябы до 200 мб опустимся, будет просто секс (несравнимо с 10мб Go, но то что сейчас точно не вариант)

Спасибо за наводку)

Может в тему будет тоже

https://www.specfy.io/blog/1-efficient-dockerfile-nodejs-in-7-steps

Я работал в компании, где у нас был гигантский enterprise на Node.js, но только там у нас не было практически ниодной внешней зависимости (кроме kafka.js): мы абсолютно все библиотеки написали сами (мы даже документарную БД поверх FoundationDB на Node.js забабахали и работало)

Но такую роскошь редко можно себе позволить в wild-life

Да и впринципе как-то устаешь от танцев вокруг приложения: "5000 RPS и 100 инстансов? хуйня вопрос" – а потом с разбегу в стену из-за стека

Я считаю это маленькой нагрузкой вокруг которой нам приходится производить слишком много танцев с бубном ну просто потому что Node.js, RMQ, а на самом деле, еще и PostgreSQL уже сильно жопу подпек, но об этом уже есть отложенные посты)

Я наверное впервые в ситуации, когда смотрю на это и понимаю насколько мне раньше везло попадать в очень точечные ситуации где сразу был Go (часто благодаря мне) или Node.js прекрасно себя чувствовал (я на него случайно с Go пересел пару лет назад, но там была просто роскошь при работе с ним, потому что очень интересный стек и много времени на DX)

И вот полтора года назад я попал в ситуацию где Node.js, RMQ и PostgreSQL просто данность и мы не могли с нее спрыгнуть

Опять же, все работает, эти 5000 RPS занимают миллисекунды, но блять какой ценой, почему я должен так много оптимизировать? Я недоволен 😁

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

Я, как человек, который разработал методичку по Бизнес-Системной аналитике и вообще начинал IT-Качалку чисто по проектированию и архитектуре исключительно ЗА такое будущее (я даже не думал пару лет назад что вернусь в full-time коддинг))

Если мне дадут превратиться в промпт-архитектора – это будет счастье

...а на самом деле он может и сотни тысячь) ...
"Ь" лишний)
по теме: сам фронт и поглядываю в сторону бека на го, можешь подсказать какие есть решения в виде фреймворков для быстрого вката(хочу пощупать что такое этот ваш go lang)?

Так ты го или фреймворк внутри го хочешь пощупать?

Если бы я был фронтом, который идет в Го, я бы сделал так:

. Выбираем проект, который будем делать (например, тиндер, но только со шлонгами)
. Для http берешь echo / gin
. Для логирования zap / zerolog
. Для конфигурации и секретов viper
. Для миграций на БД goose
. Для SQL используешь sqlx + делаешь интроспекцию через xo + компилируешь SQL запросы через sqlc
. Читаешь и повторяешь структур проекта как написано вот здесь
. Для хелперов в тестах берешь либу testify
. Для автоматизации скриптов (npm scripts) используешь makefile
. Начинаешь писать приложение
. Ничего не получается
. Синтасически вещи смотрешь здесь, примеры проектов здесь
. Гуглишь (по го миллиард бесплатных видео и текстовых туториалов)
. Начинает получатся
. Разбиваешь код по пакетам
. Удивляешься что export на CamelCase (но со временем понимаешь насколько это красиво)
. Учишся явно возвращать ошибки (это как курение: сначала противно, а потом без этого никак)
. Попадаешь на первый nil pointer
. Читаешь в чем разница передачи по Pointer vs Value и как правильно объявлять тот или иной тип
. Пишешь первую goroutine
. Они не запускаются
. Читаешь про wg.WaitGroup и ctx.Context
. Создаешь первый channel
. Попадаешь в deadlock
. Учишь for, select, последовательность открытия, коммуникации и закрытия channel
. Охапка дров, backend готов

А про framework на Go – это к @bondiano )))

да не, я мнения, что на Go удобный фреймворка (аля Rails) не построить, и я не против варианта собирать самому )

я rcnfnb примерно такой же сетап как ты и написал в итоге собрал ), btw, sqlc - тема, и слизан с кложуровской https://www.hugsql.org/getting-started :D

Интересные цифры.

Как хорошо, что за меня Гугл образы собирает. 😁 Мне казалось, что там аж меньше 100 Мб на сервис. Лень проверять. И поднятие инстанса быстрое.

Go хорош ситуативно. Node.js лучшая! 😁

Я считаю, если нравится Go, то нужно просто признаться себе и использовать его.

Еще было бы не плохо иметь качественную сравнительную таблицу где нода/раст/go/… подходит идеально , а где нет (это не только в контексте написания кода и выполнения задач но и менеджерский аспект тоже учитывать - стоимость разработки, поддержки и тд)

Мне кажется такое не реалистично. Слишком большое разнообразие возможно.

Привет, что тебе дев опс сказал ? Что там за хлам ?

На сколько образ уже сократил?

Уже было тогда поздно, а сейчас выходные, поэтому пока оставил вопрос на следующую неделю

Но как будет инфа, обязательно напишу

Кстати, ответ нашелся:

Во-первых, вместо того, чтобы последнюю фазу билдить из образа типа bookworm, там был образ билда, поменяли на bookworm, убрали 600 mb

Во-вторых, билд происходит засчет lerna и она добавляет тонну нахер ненужных зависимостей. Вот от этого пока не было времени избавляться, но в случае успеха минимум 400 mb сократим

В итоге от 1.4 Gb образа должно остаться где-то 400mb, но и это можно думаю до 300 довести