Хочется отметить, что вообще понятия джуна, миддла и синьора достаточно условные и список навыков может отличаться в зависимостей от того, чем придется заниматься. Если человек хорошо знает js, но допустим не знает как использовать монгу, то могут все равно взять на миддла, потому что понятно, что человек разберётся с таким в процессе.
На фрилансе действительно не стоит искать проекты с нуля для e-commerce на nodejs, но есть куча задач где нужно что-то поправить или прикрутить. На таком легко опыта набраться.

https://www.npmjs.com/package/websocket
или
https://www.npmjs.com/package/ws
Что лучше?
Про socket.io даже спрашивать не буду.

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

Микросервисы, это архитектурный термин, в этом контексте можно сказать, что нода подходит для любого типа задач, которое можно разделить на определённые зоны ответственности, что не очень то верно) А что если это будет какой-нибудь блокчейн или распределены математический алгоритм, подра9умевающий тяжёлые математические операции, не больно ли будет делать подобные микросервисы на ноде?

Я не понял, как логически обосновано первое предложение. Из моей фразы никак не следует, что нода подходит для любых задач, которые дробятся
Однако если кому-то в голову пришла не совсем здоровая мысль использовать ноду для математики, выделение тяжёлых операций в сервисы является возможным вариантом решения. Хотя и странным, и, наверное, более плохим, чем выведение математики в отдельный поток/процесс

Хорошо, а что по вашему есть "микросервисы"?

Элементы микросервисной архитектуры

Ну так совсем не интересно вести диалог)

Интересно, а что ещё ожидалось в качестве ответа? И зачем вообще его задавать, совсем непонятно в контексте
Вопрос же был не про архитектуру, а именно про микросервисы
А то бы я определение микросервисной архитектуры откуда-нибудь скопировал

Более точно, Нода вполне подходит для создания микросервисов, где будут интенсивные I/O операции. Для монолитов (коими чаще всего являются e-commerce платформы на PHP, Ruby, Python) и интенсивных CPU операций (привет один поток и блокировка event loop) она не подходит. А вот rest API, чаты, онлайн игры, back-end for front-end, gateway для back-end микросервисов на других языках, GraphQL - это про Ноду.

И все таки, так ли необходим тут контекст монолита или микросервиса, чтобы рассуждать о том, насколько нода подходит под тот или иной кейс. Думаю это актуально только с точки зрения сложившейся практики, но, чтобы не вводиться в заблуждение самим и других, кто прочтёт этот диалог, считаю этот момент лишним, никто не мешает юзать ноду хоть в сервисе, хоть в монолит, главное чтобы наши задачи не противоречит основной идее ноды - неблокируемый io

Многопоточность уже как 3 года есть. PHP, Ruby и Python ни чем не лучше для монолитов. Интенсивное CPU уже давно ок при помощи WASI и N-API.

Насчет CPU спасибо, покопаю. Но про PHP, Ruby, Python, я не про язык вообще, а про вполне рабочее решение из коробки. Голый язык никому не нужен.

Основная идея ноды за 10 лет изменилась, сначала она звучала как «распределенные высоконагруженные сервисы без состояния с неблокирующим I/O», теперь она звучит: «распределенные многопоточные высоконагруженные интерактивные сервисы с состоянием и неблокирующим I/O и разделяемой памятью и интенсивным CPU»

В Руби как раз многопоточности толком нет. Там сайдкик ото. 10 потоков отсилы. И то...

Почему все противопоставляют микросервисы монолитам? И ни кто не говорит про слоеную архитектуру, которая с успехом используется уже 50 лет и имеет решения для большинства обсасываемых тут проблем.

Ща это не модно😊

Микросервисы это круто, если ты с самого начала знаешь как их приготовить, но в 99% случаев, это не так.

всегда интересно откуда берётся эта статистика - 99%
она основана на личном опыте, или это такой анализ рынка был?

шарить объекты между потоками уже можно?