Возможно, вы думаете, что подобные заявления звучат слишком уж напыщенно. Однако, попробуйте поискать в Google, и вы столкнётесь с неистощимым источником бесконечных споров. Среди рассуждений не в пользу Node, которые могут вам встретиться, есть, например, такие, которые, вопрошая о том, что случилось с аксиомой об использовании лучшего из имеющихся инструментов для решения некоей задачи, указывают, что JS и рядом не стоял с правильным серверным инструментарием. Другие критические замечания о JS, вроде «Callback hell is real», призывающие поверить в реальность ада коллбэков, звучат как строчки из стихотворения. Некоторые из критиков Node выражаются более прямо и однозначно: «Node — это раковая опухоль».
Полагаю, настало время восстановить истинное положение вещей, расставить все точки над «i» в том, что касается платформы Node.js и JavaScript в роли языка серверной разработки. Сегодня мы поговорим о современном состоянии и развитии Node.js, о наиболее удачных вариантах использования этой платформы, о её ограничениях, и о технологиях, созданных на её основе.
Современное состояние Node.js как серверной платформы
Прежде чем говорить о том, как выглядит сегодня серверная платформа Node, вспомним о том, что это такое.
А именно, это среда выполнения JavaScript, построенная на базе JS-движка V8, разработанного Google и применяемого в Google Chrome. Node.js использует неблокирующую модель ввода-вывода, управляемую событиями, которая делает эту платформу простой и эффективной.
В начале этого материала Node показан как прямо-таки кошмар программиста. Однако, эта платформа не случайно стала весьма популярной. Тут мы не станем опираться на голословные утверждения. Лучше взглянем на факты. А именно, свежее исследование Stack Overflow показывает, что Node.js — это, на сегодняшний момент, самая популярная среди разработчиков технология.
Кроме того, JS — это язык, популярность которого за последние пять лет растёт быстрее, чем у других языков, при том, что C# и PHP теряют позиции. Распространённость JavaScript, если даже не говорить исключительно о Node, идёт вверх.
Как можно объяснить то, что JavaScript, в роли серверного языка, был столь быстро и широко принят сообществом разработчиков? Проще говоря, Node пережил стадию, в которой воспринимался как некая забава, и вошёл в фазу стабильности и зрелости. Вокруг него сформировалось мощное сообщество, размер которого неуклонно растёт. Экосистема Node также достойна упоминания, так как, например, менеджер пакетов Node, npm, в настоящий момент представлен самым большим реестром ПО в интернете.
Node.js не только совершил революцию в серверной разработке, но благодаря ему сделан вклад и в производительность клиентских приложений, так как к развитию V8 были привлечены серьёзные силы. Кроме того, он играет заметную роль в расширении всей экосистемы JavaScript и в совершенствовании современных JS-фреймворков, таких, как Angular, React или Vue.
С течением времени Node смог опровергнуть предрассудки ранних дней. Вот некоторые из них.
JavaScript-код для Node.js печально известен сложностью отладки.
Для отладки серверных JS-приложений можно использовать те же самые методики, которые применяются для отладки клиентского кода, применяя node-inspector, где собраны средства инструментов разработчика Chrome.
Далее, например, разработчики из Joyent, которые кое-что понимают в деле отладки и профилирования Node-приложений, уже давно выпустили универсальный отладчик DTrace.
Node нельзя использовать для разработки серверных приложений корпоративного класса.
Это утверждение тоже не соответствует действительности. На базе Node можно создавать корпоративные системы. Сложность заключается лишь в том, что в нём имеется не особенно много встроенных средств, упрощающих создание подобных систем. Однако, заметные игроки IT-рынка используют Node в качестве корпоративной веб-платформы. Среди них — Netflix. PayPal, Yahoo!, Walmart.
JavaScript — это динамический язык, поэтому, работая на нём, нельзя использовать нечто вроде статической проверки типов при компиляции.
Это правда. Однако, в экосистеме JS появились средства вроде TypeScript и Flow, которые нацелены на работу с типами в JS, что позволяет повысить стабильность и предсказуемость программ, упростить отладку. В этой сфере можно воспользоваться и возможностями Closure Compiler от Google.
JavaScript не создавался как язык для серверной разработки.
Тут можно лишь сказать, что JS уже мог работать на серверах, тогда же, когда Netscape встроила поддержку этого языка в свой браузер. А было это аж в 1995-м. JS обычно называют языком клиентской веб-разработки лишь потому, что он полностью захватил эту сферу.
На самом деле, этот список можно продолжать и продолжать.
Теперь поговорим о сценариях использования Node.js и о его ограничениях для того, чтобы лучше понять место этой технологии в современном мире.
Сценарии применения Node
Итак, зачем вообще рассматривать Node.js как средство серверной разработки в применяемом вами стеке технологий?
?Преимущества и общие характеристики
Позвольте мне в двух словах обозначить самое важное:
- Весьма вероятно, что клиентские части ваших веб-приложений написаны на JavaScript. В этом случае универсальность кода в применяемом стеке технологий — это важный плюс использования JS и на сервере, о котором стоит помнить.
- Инструменты вроде webpack помогают в повторном использовании кода и на клиенте, и на сервере, что ведёт к его единообразию на всех уровнях системы.
- Применяя JS на клиенте и на сервере, можно создавать веб-приложения, которые могут рендериться и в браузере, и на сервере. При этом такие системы обычно работают весьма чётко и понятно. Полагаю, это — просто потрясающе.
- Появление в Node конструкции async/await полностью изменило подход к написанию асинхронного кода. Теперь такой код напоминает обычный синхронный код, и по внешнему виду, и по поведению. Механизм async/await поддерживается в Node начиная с версии 7.6. Он, в частности, является решением печально известной проблемы ада коллбэков.
Некоторые видят в сближении кодовой базы клиента и сервера минус Node.js, говоря о том, что он принуждает разработчика к использованию JavaScript. Однако, это не совсем так. При необходимости из Node-приложений можно обращаться к сторонним специализированным библиотекам.
Скажем, вам нужны инструменты для кодирования видео. Для того, чтобы оснастить ими свой проект, написанный на JavaScript, вам не придётся искать какие-то малораспространённые таинственные библиотеки для Node. Вы вполне сможете воспользоваться проверенными инструментами, наладив взаимодействие с ними из Node. Или, например, если имеется некая библиотека на Python, выполняющая необходимые вам сложные вычисления, специально для работы с ней можно запустить микросервис и обращаться к соответствующим функциям этой библиотеки через REST API.
Учитывая всё вышесказанное, можно выделить следующие варианты использования Node.js, в которых он в полной мере раскрывает свои сильные стороны.
?Сценарий №1. Приложения реального времени
Приложения для совместной работы (такие, как Trello и Google Docs), интерактивные чаты, системы мгновенного обмена сообщениями и онлайн-игры — это примеры приложений реального времени, при разработке которых особенности архитектуры Node.js могут сослужить вам хорошую службу.
Время, необходимое этим приложениям для выполнения тех или иных действий, можно охарактеризовать, с точки зрения пользователя, словами «немедленно» и «сейчас». Для нормальной работы таких приложений система, на которой они основаны, должна обеспечивать очень высокую скорость отклика на действия пользователя и низкий уровень задержек. Node отвечает этим требованиям.
Node облегчает обработку множества запросов от клиентов, его архитектура способствует эффективному использованию библиотек, он обеспечивает очень быструю синхронизацию данных между клиентом и сервером.
?Сценарий №2. Одностраничные приложения
Одностраничное приложение — это приложение, которое представлено единственной загружаемой в браузер веб-страницей, содержимое которой динамически обновляется в ходе взаимодействия с ней пользователя. Большая часть нагрузки при работе таких приложений ложится на клиентскую часть системы, написанную на JavaScript.
Даже хотя одностраничные приложения — это значительный шаг в эволюции веб-разработки, есть у них и проблемы, которые, например, касаются рендеринга. В частности, это может плохо повлиять на поисковую оптимизацию страниц. Популярное решение этих проблем заключается в серверном рендеринге средствами Node.js.
?Сценарий №3. Масштабируемость
Сервер на Node никогда не окажется гораздо мощнее, чем нужно. Красота архитектуры Node заключается в её минималистичности, в том, что серверную часть приложений можно масштабировать в зависимости от потребностей проекта. Секрет тут кроется в правильном отношении к производительности.
Даже название предмета нашего разговора, «node» акцентирует внимание на возможности построения систем из множества небольших распределённых вычислительных узлов, которые могут обмениваться друг с другом данными.
Модульность Node позволяет создавать маленькие приложения, не сталкиваясь при этом с необходимостью поддержки огромной инфраструктуры, многие части которой в некоем конкретном случае окажутся незадействованными. При разработке Node-приложений программист выбирает именно то, что ему нужно, и, при необходимости, расширяет решение.
Однако, надо отметить, что подобным возможностям масштабирования сопутствуют и определённые сложности. И, если потерять бдительность, Node.js может стать… опасным.
Ограничения Node.js
Если говорить честно, то Node позволяет разработчику, что называется, «выстрелить себе в ногу». В этом мире за всё надо платить, в том числе — и за широкие возможности по настройке системы и по подгонке её под свои нужды. Если работать с Node, не имея достаточного опыта или регулярно пуская дело на самотёк — можно столкнуться с серьёзными проблемами вроде потери клиентов.
В противовес более традиционным подходам, жёстко регламентирующим те или иные архитектурные особенности систем, структуру, которая поддерживает серверную часть вашего приложения, создаёте именно вы. В результате, тут приходится принимать множество решений, то есть, разработчику необходимо точно знать — чем именно он занимается, и что будет с проектом, если его потребуется расширить.
В случае с другими языками, вроде Ruby, и широко известного фреймворка Ruby on Rails, например, в ходу идея, которая заключается в преимуществе соглашений над конфигурированием системы. Эти традиционные фреймворки буквально ведут разработчика за руку, показывая ему правильный, безопасный путь решения типичных задач.
Node переворачивает всё, так сказать, с ног на голову. Разработчику даётся больше свободы, но путь к реализации задуманного может оказаться полным опасностей, если в ходе работы будут приняты неверные решения. Тут уместно будет вспомнить о пресловутом «аде коллбэков», который вдруг окажется совершенно реальным.
Это не означает, что на Node нельзя создавать большие серверные приложения, но вышесказанное стоит постоянно держать в голове.
Даже создатель Node.js, Райан Даль, в итоге, перед переходом к другим проектам, осознал ограничения системы. Он высказался на этот счёт весьма однозначно:
«Думаю, Node — это не лучшая система для создания крупномасштабных серверных проектов. Я бы использовал для этого GO. И, честно говоря, именно поэтому я и оставляю работу над Node. Я однажды понял, что, на самом деле, это вовсе не самая лучшая система для серверной разработки».
Ранее упомянутые предубеждения, касающиеся Node, были справедливы до определённого момента не такого уж и длинного жизненного пути Node, и они, до некоторой степени, всё ещё — не пустой звук. Node достаточно повзрослел и вырос, его слабые стороны, при необходимости и наличии времени, вполне можно обойти. А инструменты, разработанные сообществом, позволяют создать на базе Node.js практически всё, что угодно.
Популярные вспомогательные средства для серверной разработки на JS
Не слишком давно, если некто задумывался о том, чтобы создавать все части своей системы на JS, в голову тут же приходила мысль о стеке MEAN (MongoDB, Express, Angular и Node).
Этот набор инструментов и в наши дни не потерял актуальности, однако, в настоящее время в экосистеме JS имеется гораздо больше интересных инструментов как для клиентской, так и для серверной разработки, поэтому не стоит ограничиваться MEAN.
Вот несколько популярных современных серверных JS-фреймворков:
- Express.js был и всё ещё является самым популярным Node.js-фреймворком. Он быстр, компактен, не навязывает разработчику жёстких архитектурных решений. В основе его стремительного развития лежит простота и понятность. Возможно, он идеологически ближе всех остальных инструментов к идеям, лежащим в основе, Node, следуя которым он представляет собой легковесную модульную систему.
- Meteor, с другой стороны, использует чистый JavaScript и Node.js внутри довольно-таки масштабной конструкции. Meteor и сам по себе — это целая экосистема, которая может подойти для разработки более сложных серверных приложений. Однако, использование Meteor может усложниться, если нужно что-то, что не встроено в систему.
- Sails.js — это MVC-фреймворк реального времени. Он был разработал для имитации шаблона MVC на платформе Ruby on Rails, но при этом подразумевал поддержку требований современных веб-приложений. Работает это всё благодаря API, которые управляются данными, при наличии масштабируемой, сервис-ориентированной архитектуры.
- Koa.js — фреймворк, созданный той же командой, которая занимается Express. Его продвигают как «фреймворк следующего поколения для Node.js». Его можно охарактеризовать как систему, которая отличается компактностью, выразительностью и надёжностью. Koa.js подходит для разработки веб-приложений и API.
Конечно, этот короткий список содержит далеко не всё, что создано для серверной разработки на базе Node. Вот ещё несколько интересных проектов: Nest.js, Hapi.js, Socket.io, Mean.js, Total.js, Derby.js и Keystone.js.
Итоги
Задача этой статьи не в том, чтобы сделать некий итоговый вывод о том, предлагает ли экосистема Node.js самые лучшие средства для серверной разработки. Здесь не идёт речь и о том, чтобы склонить кого-либо к использованию Node. Я, к тому же, не собираюсь говорить, что Node значительно превосходит другие популярные серверные среды, разработка в которых ведётся с использованием Java, C#, C++, PHP, Python, Go или Ruby.
Полагаю, самое главное, что мне хотелось сделать — так это показать, что между безапеляционными «да» и «нет», которые можно встретить во многих рассуждениях о Node и о JS как о серверном языке, если обширная область «может быть».
И, нравится это кому-нибудь или нет, интерес к Node постоянно растёт.
В завершение этого материала мне хотелось бы сказать, что не стоит относиться к любому фреймворку как к палочке-выручалочке, которая волшебным образом решит все проблемы. Node.js — это просто один из инструментов в колоссальной вселенной веб-разработки. В некоторых ситуациях он решает поставленные перед ним задачи исключительно хорошо, а в других работа с ним может превратиться в кошмар.
В задачи каждого разработчика входит тщательный подбор технологий, подходящих для реализации любого нового проекта. При этом важно учитывать все возможности и не отбрасывать сходу имеющиеся альтернативы.
Например, в компании Snipcart, где я работаю, используется архитектура .NET, о которой можно наговорить много всего нелицеприятного. Почему выбрана именно она? Да просто потому, что в конкретный момент она оказалась наилучшим инструментом для решения поставленной перед нами задачи.
Надеюсь, мой рассказ о Node поможет вам принять правильное решение при выборе серверной платформы для вашего очередного проекта.
Уважаемые читатели! Что вы думаете о серверном применении JavaScript и о Node.js? Можете ли поделиться примерами удачного (или неудачного) использования Node в реальных проектах?
Комментарии (45)
sshmakov
20.12.2017 17:23+1Вот несколько популярных современных серверных JS-фреймворков:
И ни слова о ASP/JScript
Gentlee
20.12.2017 17:44Писать большую статью про Node.js и ничего не рассказать о производительности? А про главную проблему — масштабируемость, вообще ни слова? Когда непонятно сколько процессов node нужно запускать на сервере, один? два? или больше? и почему? Проблема, которая по сути отсутствует у языков без асинхронности, таких как PHP и Python, и у языков с полноценной многопоточностью, таких как Java, C#, Go.
SirEdvin
20.12.2017 17:55+11. Эм, а в чем проблема? Сколько нужно, столько и запускается, стресс-тестирование у вас есть, автоскейлинг вроде через pm2 или docker у вас тоже есть.
2. Вы не поверите, но эта проблема есть везде. В PHP у вас процессы для apache или php-fpm, в python это у вас воркеры у вашего сервера, в java, c# и go — это пул потоков.
3. В python есть асинхронность и async/await (а раньше yeild / coroutine) и про callback hell там не слышали, потому что сразу было сделать нормально.Gentlee
20.12.2017 18:57В том то и дело, что с apache и тред пулами все более менее просто, сделал тред пул с потоками на <количество ядер процессора> и ресурсы компьютера используются по максимуму. А с Node.js нужно угадывать сколько процессов запустить, так как никогда не угадаешь сколько потоков будет использовано, даже одна нода может ядра загрузить, а может и не загрузить!
SirEdvin
20.12.2017 19:22У вас какая-то каша.
NodeJS в целом работает только на одном ядре в один поток, у него проблемы с многопоточностью (условно). А благодаря async логике для него I/O как раз не является проблемой. Ну и да, кластер тоже есть.
И вообще, что это значит "никогда не угадаешь"? Как по вашему тредпулы работают? Они, чаще всего, тоже создают треды заранее и те просто висят и тупят.
Gentlee
20.12.2017 20:01Каша все таки у Вас в голове, судя по фразе «для него I/O как раз не является проблемой». Речь вообще не про проблемы с I/O. Видимо Вы еще не дошли до того, что понял Райан Даль. Еще раз, постараюсь как можно проще.
Тред пулы создают потоки на количество ядер процессора, и программа задействует ресурсы сервера максимально эффективно, без какой либо дополнительной настройки.
В отличии от тред пулов, каждый процесс Node.js создает один поток для JS и несколько для I/O, поэтому 1) привести общее количество потоков к ядрам процессора не представляется возможным (расскажете как?) 2) из созданных потоков только один на процесс занимается JS, остальные I/O, и как же определить баланс между количеством потоков на JS и на I/O? Методом подбора! Можно ли это тогда назвать профессиональным инструментом для высоконагруженных серверов? Внятного автоскейлинга в pm2 кстати нет, по той же причине, надо задать количество процессов самому.
Почему так? Да потому то процессы Node.js — это отдельные программы, которые создают потоки столько, сколько хотят, не глядя на других. И потому что есть разделение на JS потоки и на I/O.
RPG18
20.12.2017 22:30несколько для I/O
Дайте пруф. Насколько помню, то libuv делает потоки, для асинхронной работы с файловой системой.
SirEdvin
20.12.2017 22:40Тред пулы создают потоки на количество ядер процессора, и программа задействует ресурсы сервера максимально эффективно, без какой либо дополнительной настройки.
Так просто это не работает.
1) привести общее количество потоков к ядрам процессора не представляется возможным (расскажете как?) 2) из созданных потоков только один на процесс занимается JS, остальные I/O, и как же определить баланс между количеством потоков на JS и на I/O? Методом подбора!
- А как вы это делаете в других приложениях? Берете эмпирический 2 * количество ядер + 1 процесс и запускаете.
- Так просто это не работает. Если треды на IO не нужны — они и не работают, а только едят немного RAM. Потому что есть всякие sleep, wait, ожидания внешнего события и так далее.
Вообще, вы же понимаете, что у вас в ОС выполняется куча программ одновременно и в них куча потоков. Вот так просто приводить все с рандомному n или 2 * n + 1 немного так себе.
Gentlee
21.12.2017 20:13Вообще то приводить количество потоков к количеству ядер это не так себе, а must have. Если рабочих потоков больше, то из за переключения контекста производительность падает совсем не линейно. И проблема с нодом как раз в том, что количество потоков при кластеризации никто не регулирует.
Больше я объяснять не буду, нашел интересное обсуждение на эту тему (в котором кстати сказано, что количество потоков libuv для I/O захардкожено в 4 шутки).
Быть заминусованным программистами JS даже почетно :)RPG18
22.12.2017 02:19Там не написано про использования потоков для I/O. Там обсуждается тема что-бы для фоновых потоков V8 использовал пул потоков встроенный в libuv. Так же там написано то, о чем говорил выше. Libuv использует потоки, для имитации асинхронной работы там, где ОС не предоставляет соответствующих механизмов(файловая система, dns)
Gentlee
22.12.2017 14:29Про потоки I/O (libuv) и другие потоки:
For I/O-bound work loads num_threads > num_cpus is usually acceptable, for CPU-bound loads it's not. Computing bitcoin hashes in 1,000-fold parallel on a machine that only has 8 cores is not efficient.
Libuv knows what category its own work items belong to (fs, dns — all I/O) but it doesn't know that for external work items that come in through uv_queue_work(), which is what crypto.randomBytes() and the zlib functions use, for example.
И дальше, прямо в точности что я сказал:
What's more, libuv only knows about the current process but a common use case with node is to spawn multiple processes. You don't want to get into a perfect storm situation where multiple processes think «hey, throughput times are going up, let's create some more threads.»
Gentlee
22.12.2017 16:04-1Сам факт того, что количество потоков libuv захардкожено в 4 шутки на процесс уже многое говорит о масштабируемости и эффективности :)
RPG18
22.12.2017 16:08Читайте внимательно топик и документацию к libuv. Он использует пул потоков для асинхронной работы с файловой системой и dns там, где это не поддерживается. Это никак не аффектит кейсы сходить в бд и выдать ответ.
Gentlee
23.12.2017 04:55Почитал документацию, а так же отличную статью и ответ на stackoverflow.
Libuv использует пул для всех операций с файловой системой и DNS (они блокирующие, пруф 1, пруф 2). И что еще хуже, весь user code (из подключенных библиотек) тоже будет выполняться в этом thread pool (из чего вытекает довольно интересная проблема в конце приведенной статьи). Хоть одно радует — можно поиграться с количеством потоков с помощью переменной UV_THREADPOOL_SIZE.
Получается на машине с нодами лучше вообще не подключать нативных библиотек и не работать с файловой системой, а использовать только network-I/O. Тогда переключений контекста практически не будет. Ну и конечно не выполнять серьезных CPU-вычислений в JS (либо рассмотреть хак с setTimeout, если по другому лень).
PS. Конечно для простого сайта можно вообще не париться.
PPS. Пока спорил, сам во многом разобрался. Короче не зря наспамил :).
faiwer
23.12.2017 09:06Скажите, а это правда всё имеет смысл? То, о чём вы говорите. Просто мне кажется, что попытки удержать число потоков равным числу ядер сродни попытке победить ветряную мельницу. Нужны какие-то уж очень тепличные условия, чтобы это было не так. Вынести БД за пределы node приложения, вынести nginx и подобные штуки за пределы, вынести всякие memcahed, redis и пр. за пределы, вообще всё вынести и стараться не дышать. И то не факт, что удалось всё учесть.
К тому же вы пишете — "простой сайт". Складывается ощущение, что у вас линейка дискретна: "простой сайт 1000 хитов в день" и "сложный сайт — триллионы хитов в день". Или я не прав? :)
P.S. я никогда не занимался hi-load, мне просто интересно.
Gentlee
23.12.2017 16:28Простой — имелось ввиду не hi-load.
По поводу смысла — я считаю, что надо хорошо понимать как работает инструмент, когда ты рассуждаешь о высоконагруженных серверах, где даже прирост производительности 5-10% это очень много. Про микросервисную архитектуру можете погуглить, это не я придумал.
С другой — надо конечно хорошенько это все потестировать, все таки доверять лучше цифрам а не словам. Вот только в подобной статье я и рассчитывал увидеть 1) хоть какие то цифры 2) более подробное описание слабостей Node.js.
SirEdvin
22.12.2017 17:21Вообще то приводить количество потоков к количеству ядер это не так себе, а must have. Если рабочих потоков больше, то из за переключения контекста производительность падает совсем не линейно
Вы же знаете, что у вас в системе есть там, например, ntpd, systemd и еще куча всяких демонов? А потом еще может случится так, что вы на том же сервере запускаете бд, nginx и еще что-то.
Какой смысл приводить количество потоков в приложении к ядру (и кстати, например, в Java и JVM языках это невозможно сделать) если переключений контекста все равно не избежать.
Я не использую js, но вы просто несете очень странные идеи в массы.
Gentlee
22.12.2017 18:38Переключений конечно не избежать, но очевидно их нужно минимизировать, что с nodejs сделать не удастся.
То что вы перечислили, большую часть времени спят, я же говорю про активные потоки (CPU-bound work loads). Конечно если присутствует много операций ввода вывода, то лучше запускать побольше, так как они процессор не загружают по полной.SirEdvin
23.12.2017 12:48Но ведь IO потоки тоже не будут ничего делать, они просто будут висеть до получения сигнала. Тогда в чем проблема?
И опять же таки, "но очевидно их нужно минимизировать" это не очевидно. Очевидно, что нужно оптимизировать приложение, если для вас это важно, но почему нужно минимизировать этот показатель и игнорировать остальные, мне решительно не понятно.
На практике минимизация переключений контекста, скорее всего, последние чем вы будете заниматься, сначала вас ждет увлекательный путь оптимизации взаимодействий с бд, потом самого кода, а вот потом уже выкручивание всяких таинственных ручек. И очень мало компаний и людей доходят до таинственных ручек, так как им банального этого не надо и проще еще пару серверов докупить.
cjbars
20.12.2017 18:11Все удобно, все круто круто, можете отстрелить себе ногу, можете не отстреливать.
Но ребята, кроме маркетинга есть что-то убедительное?
Вот проект Х, столько то клиентов(которые платят деньги), столько серверов, такие то параметры, столько то rps… и так далее.
Тогда продали бы, а пока кроме шумихи никакой информации.
Убедите меня, если кому не лень ))insanekrolick
20.12.2017 22:35Да, ладно, скоро 10 лет как на серверной стороне пользуют, а информации все нет…
На самом деле отличный инструмент для быстрой разработки небольших задач.
Для больших задач тоже пользуем. Не скажу, что сплошное счастье, но задача мигрировать проект с C# на nodeJS в планах на 2018.
Но реально убеждать — таки лень ;)Spiritschaser
21.12.2017 00:35> мигрировать проект с C# на nodeJS
Вот не верю. Или там на C# спагетти-код вместо нормального, или узкие места, которые нода by design преодолевает.
cjbars
21.12.2017 05:24Для небольших задач мы тоже с удовольствием используем ноду. Для сборки проектов просто песня! А вот под нагрузку ставить пока страшно. Будем потихоньку выкатывать и тестить.
Пока у нас больше вопросов чем ответов. Не все грабли прошли, а вот про грабли то статей как раз и не хватает.
vgoloviznin
21.12.2017 13:09У нас используется как внешнее АПИ, работает внутри с несколькими базами (эластик серч, дайнамо дб, редиска и тп). Нагрузка не супер большая, в среднем ~100rps на машину (50 на инстанс ноды), крутится на 2х двухядерных машинах на амазоне. Полет нормальный, с самой нодой проблем вообще не было, но и нагрузки не супер большие, но аптайм приложения довольно критичен для клиентов
sanchezzzhak
20.12.2017 22:35До переписывания модуля с пхп 5.6 на ноду проект выдерживал 400-600k
пых упирается в оперативу 10гб 70% от полного объёма сервера.
Заменил на воду тогда 4 версия нагрузки ноль, сейчас уже 8.4.модуль обслуживает 7-10 млн в час. Нагрузка 20% ядра и 800 мб оперативный, вотакой опыт
evocatus
21.12.2017 01:43Мне кажется, что при переписывании всегда проект улучшается, потому что знаешь уже всё, чего не знал вначале, когда только начинал. Интересно, что было бы если бы вы с PHP на PHP переписывали.
daemonhk
21.12.2017 07:41Кстати да, переписали бы на 7 пых и отписались бы о повышении (или нет) производительности. А так получается что «мы переписали старый код с языка X на языке Y, язык Y оказался круче». Это не сравнение.
AndreyRubankov
21.12.2017 10:08Красиво пишите, но это больше материал для «впаривания», чем технический обзор :(
Модульность Node позволяет создавать маленькие приложения, не сталкиваясь при этом с необходимостью поддержки огромной инфраструктуры, многие части которой в некоем конкретном случае окажутся незадействованными. При разработке Node-приложений программист выбирает именно то, что ему нужно, и, при необходимости, расширяет решение.
На самом деле, в этом вопросе Node ни в чем не выигрывает и не проигрывает остальным платформам (C#, Java, PHP, RoR...);
Сама же фраза «поддержка огромной инфраструктуры» – попытка показать, что у всех хуже, просто потому, что принято так считать, без каких-либо утверждений (ну вы же знаете, что там у них все сложно, да?).
А на самом деле, для все той же Node нужно разворачивать все те же LB, watchdog, etc. подымать базы данных, редисы, подымать инфраструктуру в докерах… – так чем же это легче, чем у остальных? =)
В противовес более традиционным подходам, жёстко регламентирующим те или иные архитектурные особенности систем, структуру, которая поддерживает серверную часть вашего приложения, создаёте именно вы.
Увы, тут вы лукавите больше всего.
Node очень жестко регламентирует архитектуру: «либо так, либо никак»…
И связано это с EventLoop – писать тяжелые обработчики попросту «запрещено» этой архитектурой.
Кроме того, JS — это язык, популярность которого за последние пять лет растёт быстрее, чем у других языков, при том, что C# и PHP теряют позиции.
Тут отлично подойдет старый пример с SQL. Не важно, какая платформа для бекенда – все они используют SQL, и вот из-за этого SQL становится более популярным, чем сами платформы.
JS популярен потому, что он используется в подавляющем большинстве фронтенд разработки и при этом абсолютно не важно, что на бекенде. Статистика – хорошо, но ее нужно правильно интерпретировать.
ps: Node – действительно крутая технология и за нею будущее в некоторой определенной области, но вот статьи такого плана, которые навешивают лапшу – это плохо. Данная статья – лишь пример как перетягивать одеяло и вызывать холивары.
Лучше стоит сконцентрироваться на том, чтобы делать из всего разнообразия фреймворков, языков и технологий – наилучшее решение из всех возможных.
johnfound
21.12.2017 10:37Уважаемые читатели! Что вы думаете о серверном применении JavaScript и о Node.js?
Ну, JavaScript мне и на клиенте не нравится, тем более на сервере. Лучше уж, на ассемблере, потихоньку. :D
denis_skripnik
21.12.2017 16:57Здравствуйте. Если освою Javascript, легко ли будет изучить node.js? Или разница большая, и Node новичкам в Javascript сложно будет понять?
faiwer
21.12.2017 19:19JavaScript это язык программирования. А Node это одна из платформ с этим языком. Не нужно их противопоставлять :) Слово "разница" тут не применимо.
denis_skripnik
21.12.2017 19:35Я знаю, что Node и JS — одно и то же. Под словом «разница» я имел в виду сложность изучения.
faiwer
21.12.2017 19:40И то и другое можно знать весьма поверхностно и делать успешные проекты. Не то, чтобы этот путь был правильным и рекомендуемым, но это так. JavaScript после выхода ES2015 стал довольно объёмным для изучения, при этом он обычно используется с таким огромным арсеналом утилит, что время на изучение и адаптацию может уйти весьма много. В то время как node это по сути его серверная обёртка с v8. Базовые вещи (вроде stream-ов) можно освоить очень быстро. А что-то более глубокое вам может никогда и не потребоваться. В общем при условии, что backend вам давно знаком, скажем по php, то зная JS в node и учить то толком нечего. Берёшь и пишешь, попутно лазая в документацию. А вот про JS такое сказать не могу, не зная языка, сразу запрыгнув в какую-нибудь контору, что пишет серьёзные реактивные SPA, времени на погружение и изучение может уйти оочень много.
SirEdvin
Кучей разработчиков, которых выпустили из фронт-енд загона? Меня всегда удивляло, как люди умудряются банально не замечать слона и делать вид, что основная причина популярности javascript не в том, что он ультимативно нужен для разработчки веб-сайтов.
Gemorroj
Поддерживаю.
DrMeJI
А может язык оказался настолько хорош, что после установления монополии в своей среде, начал захватывать новые области?
Может топ разработчики не такие и злые, не ставят нам 'ультиматум', а используют лучшее в своих системах?)
SirEdvin
Но почему-то всегда в качестве встроенного скриптового движка в играх все выбирают lua, как так?
DrMeJI
Кто все? При чем тут игры?
Иногда просто убивают комментарии в стиле «твой язык/стиль/по — фигня, потому что вот в этом конкретном случае лучше подходит другое».
Ладно бы еще игры были доминирующими программами или основой рынка, но нет.
Человек написал глупость в стиле «язык вышел в топ — поэтому и был принят сообществом». Причина и следствие. А спорить «что лучше» — это в другую веткую
SirEdvin
Я не даю оценку языку, я говорю, что из-за того, что уже много людей знали JavaScript, а еще куча людей писали исключительно на нем, популярность NodeJS так резко возросла.
Банально потому, что JavaScript — это язык, который хоть как-то использовал почти каждый программист, а куча людей (фронтенеров) использовали только его.
Игнорируя этот факт и аппилируя к тому, что платформа крутая, потому что ее так тепло приняли нельзя именно по этой причине.
Если бы у JavaScript была какая-то альтернатива в качестве языка для фронтенд разработки еще можно было бы что-то говорить, но так вы просто проводите неверный мысленный эксперимент. JavaScript уже был условно самым известным языком.
Это как рассуждать про то, какой крутой английский, потому что им пользуется куча людей, игнорируя исторический контекст того, почему же он стал таким распространенным в мире.
alex6636
Чем же он хорош? По моему это недоразумение, а не язык
DrMeJI
Думаю «чем же хорош Javascript» в поисковике даст больше ответов, чем я.
И довольно смело называть «недоразумением» язык, настолько широко поддерживаемый сообществом разработчиков. Не говоря о бешеных темпах развития функционала и расширения сфер использования.
L2jLiga
Упоминая про слона, вы склоняетесь к тому, что нет ничего лучше PHP для BE ?)
А если думать чуть более глубоко, то Node.JS был принят сообществом разработчиков потому что он поддерживает современную спецификацию ECMAScript, к нему можно подключать различные модули, он может спокойно общаться по API с другими частями вашего BE. Тут лишь нужно проанализировать область в которой вам нужно что-то разработать и проанализировать, а подходит ли инструмент?
На счёт фронт-енд загона — тут отдельная тема, если вы считаете, что любой может писать на JS, то я вам скажу только одно, что и я могу написать кусок говнокода на C# за 5 минут, который будет работать. А чтобы писать красиво и аккуратно тут уже понадобится опыт и навыки.
SirEdvin
Поскажите, пожалуйста, что такое "BE"?
Нет, это было к тому, что в целом до nodejs, javascript был узконаправленным языком, который использовался только в одном месте — фронтенд. А учить javascript + еще какой-то язык для того, что бы использовать его в других задачах довольно затратно по времени, вряд ли оплачивалось компаниями и потому мало кто из фронт-енд специалистов это делал.