Микроисследование ИТ-специализированного кадрового агентства 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
А запросы к серверу баз данных вы не считаете? В ваших сервисах вы большую часть времени ответа делаете вычисления или ждёте ответа от базы данных?
Чтобы не ждать ответа от БД делают кэш в памяти, а не усложняют архитектуру без необходимости.
Также процесс в простое много ресурсов не потребляет.
Как я говорил это холиварная тема, для меня лучше небольшой оверхед на процессы и железо, чем оверхед на архитектуру приложения, когда задача этого явно не требует.
Процесс в простое, конечно же, не занимает ресурсов, но и не обрабатывает входящие запросы. В итоге на выходе вы получаете загруженный на 1% многопроцессорный сервер, который может обработать параллельных запросов не больше, чем у него ядер. Запросы накапливаются в очереди, время ответа растёт, часть запросов начинает отваливаться по таймауту.
Кэшом можно решить очень ограниченный спект задач, когда у вас данные меняются очень редко и строго централизованнно. В противном случае, инвалидация кэша усложнит вашу архитектуру гораздо сильнее.
Эм, что? Откуда вы это взяли?
Ну смотрите, у вас есть, например, PHP-FPM с ограниченным max_children, вы его выставили, например, в 8 по количеству ядер процессора (больше ставить опасно, если не понимаете почему, могу объяснить отдельно). К вам пришли 100 одновременных запросов. В рамках обработки каждого запроса в отправляете запрос к серверу баз данных, который выполняется, например, 100мс. Получается, что 8 процессов-воркеров ждут 100мс, обрабатывая 8 входящих запросов, а остальные 92 попадают в очередь. Все эти 100мс у вас загрузка сервера 0%. Если предположить, что парсинг запроса и сериализация ответа занимают 1мс, то получается, что у вас процессор реально был загружен только 1мс из 100, то есть ~1%.
И вот тоже
https://thisinterestsme.com/php-fpm-settings/
For pm.max_spare_servers, multiply the number of cores on your server by 4.На современных серверах с 16-32 ядрами и парой процессоров это получится 256 одновременных запросов.
Хватит?
Вот это уже больше похоже на правду. Но если вы хотите обрабатывать >1k RPS с _одного_ ядра, то не хватит.
Просто если задрать количество процессов, ориентируясь на объём памяти, как предлагается в первой статье, то эти процессы под нагрузкой начнут "драться" за процессорное время, будет огромное количество переключений контекста, и в итоге производительность процессора деградирует https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BA%D1%81%D1%82%D0%B0