Карьера
Лиля Лучик
8888

Node.js: карьерный обзор 2019 года

Микроисследование ИТ-специализированного кадрового агентства 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 тысячам рублей.

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

Для джуниоров:

Для мидлов:

Из российских компаний 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 вопросов, честно ответив на которые, вы поймете, сколько времени у вас уйдет на закрытие вакансии разработчика.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Лиля Лучик", "author_type": "self", "tags": ["\u043d\u0430\u0451\u043c"], "comments": 132, "likes": 30, "favorites": 102, "is_advertisement": false, "subsite_label": "hr", "id": 81665, "is_wide": true, "is_ugc": true, "date": "Wed, 11 Sep 2019 18:54:13 +0300", "is_special": false }
0
{ "id": 81665, "author_id": 291779, "diff_limit": 1000, "urls": {"diff":"\/comments\/81665\/get","add":"\/comments\/81665\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/81665"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121, "last_count_and_date": null }
132 комментария
Популярные
По порядку
Написать комментарий...
6

Хм... Что-та на hh заходишь и там по нулям. Половина это фронтовые, другая половина это криптопроекты. Да и по разговорам понятно что народ наелся лапшой из колбэков, и говно архитектурой(а-ля нахерачь говна на express) и больше ноду видеть не хочет.

Ответить
2

лапшой из колбэков

Это какой то неправильный народ.

Уже как пару лет есть async / await, все неугодной оборачивается в промисы и так же awaitится. Код максимально лаконичен.

Впрочем, вы про фронтенд. Нода не в фронтенде хороша, а в микросервисах. У нас куча микросервисов висит типа подписей эцп, zip/unzip, взаимодействие с внешними сервисами, все в контейнерах докера, максимально удобно. 

Ответить
4

Нода хороша прежде всего "нативной" поддержкой неблокирующего IO. Поэтому используя её для CPU-ёмких задач "типа подписей эцп, zip/unzip" вы лишаетесь этого преимущества %) Вот "взаимодействие с внешними сервисами" - это действительно ниша Ноды. А докер никак не привязан к языку программирования, его можно использовать на любой платформе.

Про лапшу из колбеков согласен, это неактуально уже несколько лет. А для тех, кто умел нормально программировать - вообще никогда не было актуально.

Ответить
1

вы лишаетесь этого преимущества %)

У нас разные задачи :) Расширять стек там, где в данный момент мы не видим необходимости оптимизировать ресурсы, тоже в принципе бессмысленно.

Но со всем согласен)

Ответить
1

Когда нода в моде была и все активно в нее поперли, никаких асинков не было еще, были разные пакеты, которые давали возможность завернуть колбэки в более читаемый вид. Также не было никаких фреймворков, вот тебе экспрес, а дальше крутить-вертись, в итоге народ и проявлял свою буйную фантазию. Что и убило коммерческую разработку, поскольку поддерживать это все просто невозможно. А там где ты написал, сейчас go, и ноде там ловить нечего.

Ответить
2

На го вы напишите километры кода, заново изобретете половину стандартных либ и в более-менее крупном проекте выстрелите себе в ногу не единожды

Ответить
0

Это, как минимум, не соответствует действительности.

Ответить
1

А там где ты написал, сейчас go, и ноде там ловить нечего.

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

Ответить
0

Ерунда какая то

Ответить
–2

async/await - это императивщина для мигрантов из жавы и плюсов, которым начальник сказал, что нода - круто, давай чото сбацаем. Те кто в жаваскрипте живут больше пары проектов выбирают декларативный подход.

Ответить
0

Это очень и очень спорно.

Видели мы такие проекты, очень сложно разбираться в них.

Ответить
0

Это не проблема обратных вызовов — скорее неспособность разработчика делить код на части. С async/await тоже всё непросто, их надо и любят обмазывать try/catch, который который до сих пор влияет на производительность.

Ответить
0

Try-catch уже давно заоптимизирован и не даёт просадки по производительности: https://gist.github.com/wreckah/e50d58d8c6e44966dbebee626138dc56

Сорян за гист, тупо не могу вставить кусок кода в комент из буфера, он обрезается %)

"Обмазывать" каждый вызов не нужно, достаточно ловить ошибки в ключевых точках архитектуры. Например, для веб-сервиса можно ловить ошибки вызова обработчиков конкретных урлов (вью/хендлеры/контроллеры), логировать в случае возникновения и возвращать 500-й HTTP ответ. Это решит 99% всех проблем с ошибками. И только в ~ 1% бывает нужна кастомная реакция на ошибку.

Ответить
1

Hh для it почти мертв как и мой круг (последний уже догнивает).

Ответить
0

А какие сейчас ресурсы наиболее подходящие для IT?

Ответить
0

LinkedIn например.

Ответить
0

И много там вакансий для России конкретно?

Ответить
0

Много.
Удивительно что кто-то ещё не пользуется LinkedIn.

Ответить
0

Удвою, если искать удаленку по России на hh по "node.js", то в основном вакансии фронта, где нода в метках для галочки стоит. Да и к тому же в основном вакансии для сеньоров.

Ответить
0

так дело в удалёнке. поищи в москве

Ответить
5

Сразу видно, что люди пишущие комменты про колбеки, ад в сложных проектах и прочую чушь, ничего кроме js на фронте в в проектах начала нулевых или по-свежее, но написанного Васей, пишущим на php и нежелающим вникнуть в область, не видели...

Ответить
1

абсолютная тривиальная задача в ноде сделать несколько запросов в базу данных mysql, postgres оборачивается еблей с колбеками и кучей пакетов в npm с реализацией коннектора к базе данных, и каждому блять надо написать свою реализацию коннектора

Ответить
4

Вы просто не умеете

Ответить
3

этот ответ только подтверждает отсутствие какого либо понятия о современном js и Node.js в частности...

Ответить
0

А напишите какие фрэймфорки/либы и т.д. нынче актуально использовать? Пока смотрю на LoopBack 4, очень мне рекомендовали. Ну и GraphQL пробовал, но что-то дофига писанины выходит (TypeScript), наверное надо юзать код-генераторы/Swagger

Ответить
–1

на решение простейшей задачи в ноде в ответе на мой комментарий было 13 сообщений, когда в пыхе задача решается в 4-5 строки, без подключения сторонних пакетов и без очевидных багов.

мы с вами можем сойтись на том, что нода годна только для создания single page application с помощью vue, angular, react, работу с данным лучше выносить на restapi под php, go, python

Ответить
0

лол, вам скинули две строки снизу, это даже не 4 :) Утешайте себя :) NodeJS крут.

Ответить
0

Простите, вы задачу прочитали? несколько последовательных запросов к БД

Ответить
1

лоооооол... написал ещё один const anotherResult = await conn.query в третью строку — вот тебе второй последовательный запрос. Всё еще меньше 4-х строк ;)

Ответить
0

Итак. я хочу написать выборку с бд.

PHP:

1. создаем файл

2. пишем 4 строки

<?

$db = new mysqli(...)

$i = $db->query("sel * from *")->fetch_all();

var_dump($db->query("sel * from * where 'что то'=$i")->fetch_all());

3. Сохраняем

4. Proft..

нода:

1. создаем проект!!

2. Npm install express

3. идем ищем нужный плагин в npmjs среди тонны говна

4. Хоршо нашли

5. пишем index,js

6. спотыкаемся 30 раз на AWAITах, идем читать документацию, но разрабочик библиотеки ничего не задукоментировал, идем опять в npmjs, копаемся в говне, находим, о вроде работет, но нет, опять что не то, так, идем опять читать, гуглить, и только тогда что то заработает.

7. спотыкаемся на бизнес логике потому что '111'+1 = 112 а '111'-1 = '11'

8. сносим проект, уходим на PHP

Ответить
2

 Npm install express

зачем вам экспресс для этой задачи? На этом можно закончить :) PHP программист не может в NodeJS по-умолчанию, или возомнили себя всемогущим? "Ща нод поставлю, ничего сложного.... Эти JS-серы только говно могут писать на фронтенде, я видел, куда им до профессионалов... Опа, эвейты какие-то.... сложна..."

Ответить
2

И что за "проект" в Node.js, который нужно обязательно создать? %)

Ответить
0

перебрал. но npm i mysql (etc.) это не создание проекта?

Ответить
0

У меня на линуксе так же и для PHP нужно написать apt-get install php-mysqli. И я тоже не понимаю, в чём разница между mysqli и mysql, пока специально это не загуглю.

Слухи о мусорности npm, конечно, не на пустом месте появились, как и то, что js-разработчики оценивают либы по количеству звёздочек на гитхабе %) Но гугл и здесь помогает, nodejs mysql даёт релевантный ответ на первом месте.

Ответить
0

буду благодарен, если вы порекомендуюте курсы, статьи, где это все описывается, вакханалия с библиотеками, чем отличается @mysql от mysql

гугл меня не понмает

мне симпатична нода например работой с телеграм ботами, хотя если что то приходит не то - все падает к хуям, но это мои кривые руки не умеют работать с try catch

но за непонятный npm - где каждый васян хочет запихнуть что то свое - нода вызывает отторжение

Ответить
0

соглашусь, что в Node/NPM развелось уж через чур много библиотек, и найти что-то, особенно если не специализируешься на NodeJS, бывает не просто и в итоге наступаешь на грабли и плюёшься :(

Ответить
0

Вот хороший сайт, с которого можно начать: https://nodejs.dev/

Если вы ищете крутой веб-фреймворк на Node.js, то посмотрите на Nest.js или Meteor.js. Я люблю простые вещи, потому что их проще поддерживать, поэтому мой выбор это Koa.js (современный аналог Express.js)

Ответить
1

очевидно, если надо нарисовать это все на сайте - привет эксперсс. Тут да, перебрал. 

и да, нода мне сложна

Ответить
3

Пакет нужен ровно один - либа для работы с базой. Где здесь хотя бы один колбек?

```

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 вообще не уверен.

Ответить
–1

Сомнительная фича, конечно. Тут только одно преимущество: если клиент использует пул подключений, то запросы уйдут по разным соединениям параллельно.

Но тут именно преимущество самого ивент лупа, а не клиента БД.

Ответить
0

Да, это преимущество Node.js в целом. Фича очень крутая. Только подумайте, у вас один процесс на PHP может обрабатывать только один клиентский запрос одновременно, а один процесс на Ноде - 1000 клиентских запросов, если основное время при генерации ответа уходит на ожидание ответов от базы или внешних API.

Ответить
0

С другой стороны, на том же go вам будет из коробки те же ивенты, строгая типизация, меньший футпринт по памяти и та-дам! нормальный мультитрединг.

Так что все в мире относительно

Ответить
1

у ноды уже тоже есть та-дам! мультитрдинг, только мне пока ни разу не был нужен

Ответить
0

Согласен Node.js по области применения конкурирует именно с Go, а не с "классическими" интерпретируемыми ЯП.

Ответить
1

У го там своих недостатков хватает, так что нода еще поживет.

Опять же, все зависит от области применения.

Ответить
0

давайте на чистоту. в го нет "нормального мультитрединга". вы не можете создавать потоки. горутина != поток. Например сравните https://play.golang.org/p/QAqZT-M2_my и https://play.golang.org/p/1DTkOUYnQKX

Ответить
0

По второй ссылке зачем бесконеечный  ( fir{} )   цикл в горутине?.... если нужно паузу сделать или приостановить правильнее канал использовать... а бесконечный цикл - это просто глупость какая то.

Ответить
0

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

для людей, которые не делают глупости, объясняю, что если у вас есть некий алгоритм, который при определенных параметрах вырождается в бесконечный цикл или просто "очень долго работает", в нем нет вызовов runtime.Gosched() и вы используете этот алгоритм в сервисе, то на условной четырехядерной машине, можно 4мя запросами положить ваш сервис. и большой разница Это к слову о "нативном мультитрединге".

Ответить
0

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

Ответить
0

Вот, я нашёл либу для PHP с неблокирующей сетью: https://reactphp.org/

Используя её, можно сделать что-то похожее на Node.js.

Ответить
0

ReactPHP уже 7 лет есть.

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

Ответить
1

Вы серьёзно?! Любой веб-сервис, который использует базу данных и внешние API, и при этом имеет большее количество одновременных пользователей, чем ядер CPU - это идеальный случай применения для платформ с неблокирующим IO.

Ответить
0

Несогласен, но холивар разводить не хочу.

Реально где это нужно, когда есть по 200 запросов к внешним API, как у автора вот тут https://habr.com/ru/post/278755/

Таких кейсов один на 1000

Ответить
0

А запросы к серверу баз данных вы не считаете? В ваших сервисах вы большую часть времени ответа делаете вычисления или ждёте ответа от базы данных?

Ответить
0

Чтобы не ждать ответа от БД делают кэш в памяти, а не усложняют архитектуру без необходимости.

Также процесс в простое много ресурсов не потребляет.

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

Ответить
0

Прелесть Node.js как раз в том, что не нужно усложнять архитектуру, не нужно изучать дополнительные фреймворки и библиотеки, разаработчики Node.js уже всё сделали за вас. Вы можете писать в "синхронном" стиле, просто добавляя слово await перед сетевыми запросами. Всё.

Ответить
0

Что оверхед архитектуры скрыт от вас фреймворком, это еще не значит что его нету.

С одноразовыми PHP процессами не требуется думать об утечках памяти и о других прелестях асинхронности.

Ответить
0

Процесс в простое, конечно же, не занимает ресурсов, но и не обрабатывает входящие запросы. В итоге на выходе вы получаете загруженный на 1% многопроцессорный сервер, который может обработать параллельных запросов не больше, чем у него ядер. Запросы накапливаются в очереди, время ответа растёт, часть запросов начинает отваливаться по таймауту.

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

Ответить
0

В итоге на выходе вы получаете загруженный на 1% многопроцессорный сервер, который может обработать параллельных запросов не больше, чем у него ядер.

Эм, что? Откуда вы это взяли?

Ответить
0

Ну смотрите, у вас есть, например, PHP-FPM с ограниченным max_children, вы его выставили, например, в 8 по количеству ядер процессора (больше ставить опасно, если не понимаете почему, могу объяснить отдельно). К вам пришли 100 одновременных запросов. В рамках обработки каждого запроса в отправляете запрос к серверу баз данных, который выполняется, например, 100мс. Получается, что 8 процессов-воркеров ждут 100мс, обрабатывая 8 входящих запросов, а остальные 92 попадают в очередь. Все эти 100мс у вас загрузка сервера 0%. Если предположить, что парсинг запроса и сериализация ответа занимают 1мс, то получается, что у вас процессор реально был загружен только 1мс из 100, то есть ~1%.

Ответить
0

Ну смотрите, у вас есть, например, PHP-FPM с ограниченным max_children, вы его выставили, например, в 8 по количеству ядер процессора

https://serversforhackers.com/c/php-fpm-process-management

Now we can decide how many processes the server is allowed to spin up.

Here's a generic formula:

Total Max Processes = (Total Ram - (Used Ram + Buffer)) / (Memory per php process)

This server is has about 3.5gb of ram. Let's say PHP uses about 30mb of ram per request.

We can start with: (1024*3.5) / 30 = 119.46. Let's just go with 100 max servers.

Ответить
0

И вот тоже

https://thisinterestsme.com/php-fpm-settings/

For pm.max_spare_servers, multiply the number of cores on your server by 4.

На современных серверах с 16-32 ядрами и парой процессоров это получится 256 одновременных запросов.

Хватит?

Ответить
0

Вот это уже больше похоже на правду. Но если вы хотите обрабатывать >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

Ответить
0

Статья описывает старое доброе распараллеливание обработки через форк процессов. Это то, как работает PHP-FPM. Использование неблокирующего IO - это немного другая парадигма. Физически вы по-прежнему остаётесь однопоточным, никаких параллельных действий не осуществляется. Просто все операции с сетью или файловой системой перестают быть блокирующими, позволяя вам вместо ожидания занимать CPU полезной работой. То есть это просто более качественный способ утилизации процессорного времени ваших серверов.

Ответить
0

Статья описывает старое доброе распараллеливание обработки через форк процессов

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

То есть это просто более качественный способ утилизации процессорного времени ваших серверов.

Я про это свою позицию уже написал выше.

Железо недорогое, мне проще добавить его чем искать утечки памяти.

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

Ответить
0

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

В однопоточных блокирующих системах количество параллельно обрабатываемых запросов равно количеству процессов-воркеров. Если вы наплодите этих процессов сильно больше, чем у вас ядер на сервере, то он приляжет под нагрузкой, потому что процессы будут "драться" за процессор. Грубо говоря, сервер попытается одновременно обработать больше запросов, чем он физически способен. Вместо того, чтобы выстроить их в очередь перед сервером и попробовать обработать частями. Поэтому ограничение на количество воркеров нужно. И подбирать его нужно под вашу конкретную нагрузку, а не исходя из чьих-то формул. Например, для сервисов, которые занимаются только вычислениями, типа обработки видео, для лучшей производительности нужно иметь строго 1 процесс на ядро. Если же у вас веб-сервис, который ходит в бд или внешние api, то можно приподнять количество процессов выше количества ядер. Но это вам придётся всегда делать вручную. Мониторить нагрузку, править конфиги. Системы с неблокирующим IO получаются практически самобалансируемыми. Единственное, что для них нужно мониторить - это потребление CPU, если оно приближается к 100%, то нужно срочно добавлять новый сервер в ваш кластер.

Ответить
0

то он приляжет под нагрузкой, потому что процессы будут "драться" за процессор. Грубо говоря, сервер попытается одновременно обработать больше запросов, чем он физически способен

У вас постоянно крайности, с одним процессом на ядро у вас сервер занят на 1%, а если больше, то сразу приляжет под нагрузкой ))

С чего процессам драться, если, по вашим словам, они тупо простаивают и ждут ответа от БД?

Никто не делает один процесс на одно ядро, вы какие-то сказки рассказываете.

Все сайты как-то работают и не испытывают с этим проблем.

Ответить
0

 Вы уж определитесь, то у вас сервер занят на 1%, то он приляжет под нагрузкой ))

Если вы сделаете 1 ядро -> 1 воркер, то будет загружен на 1% на сервисах с хождением в бд и внешние апи. Если сделаете 1 ядро -> 100 воркеров, то приляжет. Хорошее количество воркеров где-то посередине, но вам нужно его найти экспериментально на вашей кодовой базе. И оно может меняться вместе с профилем нагрузки.

Ответить
0

Ну вот, оказывается не один процесс на ядро )

Я уже выше написал, 4 процесса на ядро это полностью безопасно (там за памятью больше надо смотреть но и с этим на сервере нормально), и это уже дает лимит в сотни параллельных процессов на современном сервере.

Проблемы никакой нет, как и нет необходимости использовать асинхронный фреймворк в 99% серверных приложений.

Ответить
0

4 для веб-сервиса - это безопасно, но не оптимально. Хотя, например, если у вас там есть эндпоинт для загрузки и кропа аватарок, то уже не так безопасно. Если у вас есть монолитное веб-приложение, где один запрос обрабатывается 1мс, а другой - 10с (например, генерация какого-нибудь дикого отчёта в админке с кучей запросов в бд) и блокирует воркер целиком, то платформа с неблокирующим IO очень подходит. И это точно не 1% серверных систем.

Ответить
0

С обработкой изображений постоянный процесс быстрее сдохнет из-за утечек памяти.

Для долгих ответов API кэширование решает.

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

Ответить
0

Нет. PHP-FPM - это менеджер пула процессов. Но каждый процесс в пуле обрабатывает одновременно всего один запрос. Таким образом, если у вас сервер с 8 ядрами, вы можете поднять 8 процессов-воркеров, каждый из которых будет обрабатывать по одному запросу одновременно. Получается, что пропускная способность вашего сервиса - 8 конкурентных запросов. Например, если сервис ходит несколько раз в базу данных или какой-нибудь внешний API, и отвечает за 200мс, то вы сможете выжать из него 40 RPS.

Node.js базируется на эвент-лупе с неблокирующим IO. Все сетевые, файловые операции - неблокирующие. Поэтому даже в рамках одного процесса после того как он отправит запрос в базу, он не будет тупо ждать ответа как в PHP, а продолжит обрабатывать другие входящие запросы. То есть один процесс-воркер сможет обрабатывать от 1 (если сервис занимается CPU-вычислениями, никуда не ходит) до 1000 (если сервис ходит в базу и внешние API, а из вычислений только парсинг запроса и сериализация ответа) одновременных запросов. Таким образом в теории вы можете получить до 40000 RPS с 8-ядерного сервера.

Ответить
0

Если API отвечает 200 мс - значит его надо кешировать.

и как отметили в комментарии - есть reactphp, swoole

Ответить
0

Хорошо, не 200, а 5. Разница в подходах останется прежней.

Ответить
0

Ну и как, много проектов вы сделали на reactphp или swoole? А прелесть Node.js в том, что даже начинающий разработчик сделает свой сервис более производительным "из коробки". И для этого не нужно осваивать дополнительные фреймворки/библиотеки или изучать синтаксис го-рутин. Вот и вся разница.

Ответить
0

Что то вы усложняете.

Ответить
3

согласен, еще та хрень найти вменяемую ORM в ноде ( не, не надо предлагать TypeORM, еще то днище с кучей багов )

а фреймворк полноценный ? нету такого в ноде

все собирается хрен пойми с каких пакетов

взрослых инстурментов нету как по мне

тебе проще написать на PHP в котором давно уже все есть, все пакеты, много фреймворков, хороший consulting

Ответить
1

Вы точно в теме?

Ответить
2

Ну доля правды в этом есть. TypeORM ни разу не Entity framework.

Все остальное - доводы человека, который не пишет на JS и отстал по времени года на 3.

Ответить
1

Typeorm сырая. Давно существует Sequelize, с typescript самое оно. Не без нюансов, но в целом и общем отличный вариант

Полноценный фреймворк - Nest.js

Ответить
0

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

Ответить
0

badoo достаточно высоконагруженый сервис использует php, плюс местами go

фейсы использовали hhvm в основе php, сейчас незнаю как

Ответить
0

Баду начинался, когда никакого Node.js или Go в помине не было. Думаю, сейчас бы они сразу писали публичные части сервиса на Go.

Ответить
1

Спасибо за статью. По поводу прогнозов, когда ЯП уйдет в тираж - тут такое себе. Джаву уже с каких времен каждый год "хоронят" прогнозы. Думаю, не стоит основываться на них и принимать серьезные решения. Это я о долгосрочных. Краткосрочные прогнозы - да. Тут все, до тоски, стабильно.

Ответить
1

есть ли смысл вообще специализироваться на JS и Node, если тренды идут в сторону мобайл и Kotlin, Java всякие?!

Ответить
4

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

Ответить
0

Мобилки же не вытеснят всё, поэтому, конечно, смысл есть :)

Ответить
0

И их на ноде  кодят, хотя, решение сомнительное, на мой взгляд.

Ответить
0

Мобилки на ноде? Может PWA-фронт, который выпилит с рынка нативные приложеньки?

Ответить
3

Смотреть react native

Ответить
2

имею ввиду фреймворки, типа ионика

Ответить
0

В вопросе, конкретно, JS и Node не разбираюсь. Совет не дам. Котлин и Джава, хоть и не тренд, как вы сказали, но еще долго будут в топах используемых технологий. 

Ответить
0

сам язык, т.е. его синтаксис - это лишь малая часть того, что должен знать программист. Очень малая. Если вы освоите профессию программиста, то выучить синтаксис другого языка будет просто.

Ответить
1

Можно примеры node.js из жизни?

Ответить
1

Весь back Trello на ноде. Представьте, что происходит по клику или изменению карточки задачи. Вот и пример.

А если пример кода JS - гугль в помощь, "пример приложения на Node.js"

Ответить
0

Мы строим на нем свою блокчейн-платформу, хотя многим это кажется странно.
По факту node.js сейчас отлично подходит почти для всего, начиная от скриптов автоматизации, тестирования и тд, заканчивая сложными и крупными сервисами

Ответить
0

Спасибо. Как оно вообще на js на сервере? Не бывает желания сбежать в Java или тот же PHP?
Кстати, почему выбор пал делать блокчейн на node.js?

Ответить
2

Или открыть пекарню?

Ответить
0

Js на сервере - отлично.  Я сам как раз ушел с php, и сделал выбор именно в пользу ноды. Есть некоторая разница в паттернах проектирования, и как правильно сделать приложение так, что бы оно удачно масштабировалось. Важный момент - чистый js сильно расслабляет программиста, и иногда надо заставлять себя писать понятный код, а не как было бы короче.

Относительно блокчейн - удобство и стоимость разработки. Мы обходимся силами не очень дорогой команды, состоящей в основном из миддлов, и такая экономия хорошо отражается на возможности пережить кризис. Ко всему прочему сам js также развивается очень активно, что позволяет, опять же дёшево, привносить в проект что то новое.

Ответить
0

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

Не в курсе за блокчейн, мож там все просто, но делать проект со сложной предметной областью на JS - это ад. 

Ответить
1

JS разработчики среднего в среднем дешевле, чем Java разработчики.

Я не хочу углубляться в сравнение языков на уровне проще-лучше-быстрее - у каждого будет свой взгляд на этот вопрос.

Относительно вопроса выше, подходит-ли Node.js для продакшена и существуют-ли написанные на нём проекты, больше 10 тыс строк кода, которые находятся в постоянной поддержке и доработке - да, существуют.

Ответить
0

10 KLOC - это ни о чём, максимум год для одного человека

Ответить
0

Это не мало.

Ответить
0

Чего? Чего?

Ответить
1

Ну хотя бы пару задач, чтобы сказать - "Вот этот программист стоит этих 50к. рубасов, нужно сделать вот "такую штуку"".

Ответить
1

Так дайте пару примеров задач, вам и ответят парой примерами решений.

Ответить
0

Беккенд для финансового стартапа, со всем чем только можно, от клиентского айпи до криптовалютых контрактов. Node + typescript.

Ответить
1

Интересно, осталась ли ещё сфера в IT, где даже новичков "с руками" отрывают. Или уже нет такого нигде?

Ответить
1

Если у новичков руки и мозги на месте (выясняется на собеседовании) и видно, что у него есть явная тенденция к самостоятельному обучению/росту. Да, за таких хватаются.

Ответить
1

За 400к в месяц - да, вполне.

Такие сейчас цены на senior JS-девов.

Ответить
0

Это если заокеан на удалёнке

Ответить
0

Не надо заокеан, ближнее зарубежье: Прибалтика, Украина.

А в чем преимущество офиса перед удаленкой? Утром на работу по пробкам или метро добираться?

Ответить
1

Я как раз таки фанат удалёнки, уже как года три.

Прибалтика и Украина - обычно видел варианты с потолком в 300к.

Ответить
2

На руки так и выходит, если по-белому. Но на месте.

Ответить
0

Кто-нибудь, объясните, пожалуйста, что такое статическая типизация в ноде, а то я джун, но хочу 100к+

Ответить
1

Это когда типизация не динамическая)

Ответить
0

Хочешь позицию миддла? Учись искать жемчуг (решения) в тоннах г**** (не совсем актуальных справочниках, тьюториалах и SO)

Ответить
0

Пишешь такой ts код с типами переменной, а конпелятор тебе ругается, если пытаешься передать строку вместо числа. Что, правда, не мешает так сделать в продакшене.

Ответить
0

Окей. А динамическая тогда что?

Ответить
0

У переменной или параметра функции может быть любой тип и значение можно невозбранно менять на более другой тип. 

Ответить
0

Благодарю. Для меня фраза "умеет применять статическую и динамическую типизацию" с картинки про миддла всё ещё звучит как буллщит. Как считаете?

Ответить
0

Динамическая типизация для мидла - это скорее про приведение типов, что-то вроде 

1 == "1"

1 !== "1"

а статическая - про typescript и аналогичные.

Несмотря на то, что статической типизации в js по умолчанию нет, она всё равно подразумевается, особенно в экспортируемых модулях. Пользователь может на вход передать любую упячку, а поскольку компилятора нет, то разработчик должен самостоятельно во время исполнения проверять типы, ну и как можно подробней описать параметры функции в документации.

Ответить
0

Может кому будет интересна работа программистом node.js или python в Москве с достойной компенсацией? Если интересно, пишите мне в Telegram @alex_kryukov

Ответить
0

Мы в Jivosite активно используем ноду в проде в качестве бэкенда для real-time, в основном в сервисе чатов. Не используем express и похожие либы, в основном свое. По нагрузке около 3.5М сообщений в сутки, 1М одновременных коннектов. По опыту, позицию на удалёнке закрываем 2-4 недели.

Ответить
0

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

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }