Микроисследование ИТ-специализированного кадрового агентства Spice IT Recruitment о текущей ситуации на рынке труда Node.js-разработчиков.
Мы в Spice IT уже десять лет занимаемся подбором ИТ-специалистов, поэтому знаем инсайты (и инсайдеров!) рынка каждой из профобластей.
Ведущий консультант Spice IT Юлия Артемова поговорила с тимлидами компаний, использующих Node.js в разработке, а Юлия Попова оформила результаты этих интервью в яркие иллюстрации.
Кроме того, в конце материала будет тест, (ладно, тут он тоже будет, вот он) с помощью которого можно спрогнозировать, за какое время у вас закроется вакансия разработчика вообще, и Node.js-разработчика в частности. Особенно полезен этот тест будет для ИТ-рекрутеров, а также для нанимающих менеджеров со стороны компаний.
По данным исследования Stackoverflow, Node.js, наряду с JavaScript, лидирует в рейтинге наиболее желанных и часто используемых технологий. А вот еще какие тренды мы выделили по результатам опросов наших респондентов.
Несмотря на то, что Node.js постоянно меняется, требования к разработчикам остаются — в общих чертах — неизменными.
Тимлиды как нанимающая сторона ждут от джуниоров базовых знаний JS, от мидлов — умения работать с фреймворками, а от синиоров — способности самостоятельно решать абстрактные задачи.
Медианные зарплаты начинаются от 50 тысяч рублей (для джуниоров) и достигают 250 тысяч рублей (для синиоров).
Востребованность разработчиков каждого из грейдов легко оценить по количеству офферов за две недели активного поиска.
Какие скиллы делают выше стоимость разработчиков на рынке труда:
- RabbitMQ, Kafka.
- Elastic Search.
- Docker, Kubernetes.
- Опыт с Highload.
- Свободный английский.
Для мидлов зарплатная вилка при наличии вышеперечисленных навыков уверенно приблизится к 180 тысячам рублей. Для синиоров — к 250 тысячам рублей.
Прокачивать скиллы можно (и нужно!) с помощью постоянного самообразования. Вот несколько книг, горячо рекомендованных нашими респондентами к изучению.
Для джуниоров:
- Beginning Node.js от Basarat Ali Syed.
- Code Complete от Steve McConnell.
- Learning Node: Moving to the Server-Side от Shelley Powers.
- Node.js for Embedded Systems от Patrick Mulder и Kelsey Breseman.
- Refactoring от Kent Beck и Martin Fowler.
- Patterns of Enterprise Application Architecture от Martin Fowler (полезно всем, кроме фронтендеров).
- Node.js Design Patterns от Mario Casciaro.
Для мидлов:
Из российских компаний Node.js в разработке используют (just to name a few): Rambler, «Яндекс», МТС, «Лаборатория Касперского», «ВКонтакте», EPAM, 2GIS, OneTwoTrip, «Сбербанк», Leroy Merlin, FxPro, Zecurion, LATOKEN, Waves, «Туту.ру», «Сравни.ру», Altarix, «Тинькофф», MERA, Profi.ru.
Из зарубежных (опять же just to name a few): PayPal, Netflix, Uber, LinkedIn, Ebay, Walmart, Medium, GoDaddy, Mozilla, Trello.
Если вы уже ищите или в скором времени планируете искать работу как Node.js-разработчик, наши респонденты советуют обратить внимание в первую очередь именно на эти компании.
В качестве бонуса (для тех, кто дочитал) мы составили несложный тест из 15 вопросов, честно ответив на которые, вы поймете, сколько времени у вас уйдет на закрытие вакансии разработчика.
Сразу видно, что люди пишущие комменты про колбеки, ад в сложных проектах и прочую чушь, ничего кроме js на фронте в в проектах начала нулевых или по-свежее, но написанного Васей, пишущим на php и нежелающим вникнуть в область, не видели...
абсолютная тривиальная задача в ноде сделать несколько запросов в базу данных mysql, postgres оборачивается еблей с колбеками и кучей пакетов в npm с реализацией коннектора к базе данных, и каждому блять надо написать свою реализацию коннектора
Пакет нужен ровно один - либа для работы с базой. Где здесь хотя бы один колбек?
```
const conn = Pool.connect('DSN');
const user = await conn.query({
text: 'SELECT * FROM users WHERE id=$1',
values: [1],
name: 'select_user' // Prepared statement's name
});
```
И тут, внимание, киллер-фича - параллельное выполнение запросов к базе:
```
const [users, products] = await Promise.all([
conn1.query(),
conn2.query()
]);
```
И если в питоне так сделать можно при помощи дополнительных библиотек, то в PHP вообще не уверен.
Сомнительная фича, конечно. Тут только одно преимущество: если клиент использует пул подключений, то запросы уйдут по разным соединениям параллельно.
Но тут именно преимущество самого ивент лупа, а не клиента БД.
Да, это преимущество Node.js в целом. Фича очень крутая. Только подумайте, у вас один процесс на PHP может обрабатывать только один клиентский запрос одновременно, а один процесс на Ноде - 1000 клиентских запросов, если основное время при генерации ответа уходит на ожидание ответов от базы или внешних API.
php-fpm, не?
Вот, я нашёл либу для PHP с неблокирующей сетью: https://reactphp.org/
Используя её, можно сделать что-то похожее на Node.js.
ReactPHP уже 7 лет есть.
Только таких задач очень мало, где реально требуется ассинхронный фреймворк. Инкапусуляция одного запроса на один процесс это не недостаток, а способ параллелизма без головной боли и без необходимости вообще думать про паралельное выполнение.
Вы серьёзно?! Любой веб-сервис, который использует базу данных и внешние API, и при этом имеет большее количество одновременных пользователей, чем ядер CPU - это идеальный случай применения для платформ с неблокирующим IO.
Несогласен, но холивар разводить не хочу.
Реально где это нужно, когда есть по 200 запросов к внешним API, как у автора вот тут https://habr.com/ru/post/278755/
Таких кейсов один на 1000
Статья описывает старое доброе распараллеливание обработки через форк процессов. Это то, как работает PHP-FPM. Использование неблокирующего IO - это немного другая парадигма. Физически вы по-прежнему остаётесь однопоточным, никаких параллельных действий не осуществляется. Просто все операции с сетью или файловой системой перестают быть блокирующими, позволяя вам вместо ожидания занимать CPU полезной работой. То есть это просто более качественный способ утилизации процессорного времени ваших серверов.
И? Нету никакого ограничения, что число параллельных запросов не может быть больше числа ядер, как вы утверждали.
То есть это просто более качественный способ утилизации процессорного времени ваших серверов.Я про это свою позицию уже написал выше.
Железо недорогое, мне проще добавить его чем искать утечки памяти.
Нет смысла усложнять и вводить лишние парадигмы, где это не требуется задачами.
В однопоточных блокирующих системах количество параллельно обрабатываемых запросов равно количеству процессов-воркеров. Если вы наплодите этих процессов сильно больше, чем у вас ядер на сервере, то он приляжет под нагрузкой, потому что процессы будут "драться" за процессор. Грубо говоря, сервер попытается одновременно обработать больше запросов, чем он физически способен. Вместо того, чтобы выстроить их в очередь перед сервером и попробовать обработать частями. Поэтому ограничение на количество воркеров нужно. И подбирать его нужно под вашу конкретную нагрузку, а не исходя из чьих-то формул. Например, для сервисов, которые занимаются только вычислениями, типа обработки видео, для лучшей производительности нужно иметь строго 1 процесс на ядро. Если же у вас веб-сервис, который ходит в бд или внешние api, то можно приподнять количество процессов выше количества ядер. Но это вам придётся всегда делать вручную. Мониторить нагрузку, править конфиги. Системы с неблокирующим IO получаются практически самобалансируемыми. Единственное, что для них нужно мониторить - это потребление CPU, если оно приближается к 100%, то нужно срочно добавлять новый сервер в ваш кластер.
У вас постоянно крайности, с одним процессом на ядро у вас сервер занят на 1%, а если больше, то сразу приляжет под нагрузкой ))
С чего процессам драться, если, по вашим словам, они тупо простаивают и ждут ответа от БД?
Никто не делает один процесс на одно ядро, вы какие-то сказки рассказываете.
Все сайты как-то работают и не испытывают с этим проблем.
Если вы сделаете 1 ядро -> 1 воркер, то будет загружен на 1% на сервисах с хождением в бд и внешние апи. Если сделаете 1 ядро -> 100 воркеров, то приляжет. Хорошее количество воркеров где-то посередине, но вам нужно его найти экспериментально на вашей кодовой базе. И оно может меняться вместе с профилем нагрузки.
Ну вот, оказывается не один процесс на ядро )
Я уже выше написал, 4 процесса на ядро это полностью безопасно (там за памятью больше надо смотреть но и с этим на сервере нормально), и это уже дает лимит в сотни параллельных процессов на современном сервере.
Проблемы никакой нет, как и нет необходимости использовать асинхронный фреймворк в 99% серверных приложений.
4 для веб-сервиса - это безопасно, но не оптимально. Хотя, например, если у вас там есть эндпоинт для загрузки и кропа аватарок, то уже не так безопасно. Если у вас есть монолитное веб-приложение, где один запрос обрабатывается 1мс, а другой - 10с (например, генерация какого-нибудь дикого отчёта в админке с кучей запросов в бд) и блокирует воркер целиком, то платформа с неблокирующим IO очень подходит. И это точно не 1% серверных систем.
С обработкой изображений постоянный процесс быстрее сдохнет из-за утечек памяти.
Для долгих ответов API кэширование решает.
Асинхронность не нужна, кроме ускоспециализированных случаев где нужно тысячи соединений держать, типа чатов итп.