Выполнение javascript на сервере IIS. Сценарии применения Node

Node.js: серверный JavaScript

Duration 27:19:05

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

Пройдя курс, вы научитесь

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

Использовать технологию WebSocket и библиотеку socket.io.
Приложения реального времени в настоящее время — практически стандарт. Нет никакой необходимости в перезагрузках страницы, и не важно, нужно ли вам написать простенький чат, или высоконагруженный сервис. Сокеты помогут настроить обмен данными между клиентом и сервером с невероятной скоростью.

Разворачивать готовый проект на хостинге.
Для приложений, разработанных в среде Node.js, классический хостинг не подходит. Мы научимся разворачивать ваше приложение прямо из git-репозитория с максимальный комфортом на самых популярных подходящих площадках.

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

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

Использовать фреймворки Express.js и Koa.js в разработке.
В среде Node.js, помимо модулей и подключаемых библиотек, существуют два замечательных фреймворка, которые значительно облегчают процесс разработки. Более того, некоторые из подключаемых библиотек, написаны именно под фреймворки. Мы рассмотрим два самых популярных и известных фреймворка для разработки в среде Node.js.

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

Работать с реляционными и нереляционными базами данных под Node.js.
При разработке серверной части приложения особое внимание стоит уделить работе с данными. Выбор базы данных для проекта — крайне важный процесс, поэтому мы рассмотрим самые часто используемые типы баз данных. Для примера нереляционных баз будет использована MongoDB, для примера реляционных — PostgreSQL.

Посторонись, пресловутый PHP! Долой Java! Старичок Perl, тебе так вообще давно пора на пенсию. И как же вы уже достали, попсовые Ruby и Python! Все эти давно знакомые технологии уже не торкают. Зато сегодня мы посмотрим на чрезвычайно прогрессивный подход, когда для написания серверного кода используется… JavaScript.

Есть идея для стартапа. Теперь вопрос: на чем его писать? Конечно, есть всеми любимый РНР - что может быть легче для веб-сайта! Но скажи честно, как-то не тянет, правда? Ведь чтобы сделать что-то стоящее, голого РНР не хватит. Сразу придется прикручивать еще и AJAX, чтобы данные незаметно подгружались без обновления всей страницы целиком, да и это не решит всех проблем. О том, что PHP не так хорош, ты задумаешься в тот самый момент, когда к тебе разом ломанется много народа. А все потому что РНР (как и подавляющее большинство других языков, на которых строят сайты) даже в нашем, черт подери, двадцать первом веке, работают по классической схеме «запрос-ответ». Запрос страницы заставляет веб-сервер поднять указанный скрипт, выполнить его (линейно, строка за строкой весь твой код), а результат возвратить браузеру клиента. После этого скрипт «умирает», а следующий же запрос запустит всю эту адскую машинку заново. А если таких запросов одновременно тысяча? Старый добрый подход называется CGI (интерфейс взаимодействия веб-сервера и интерпретатора языка, на котором написана страница). Хитрые надстройки вроде FastCGI расширяют протокол, позволяя избежать выгрузки скрипта после первого запроса. Таким образом, когда второй пользователь запросит ту же страницу, для него будет уже все готово, останется только выполнить скрипт с новыми параметрами. Но все эти ухищрения - все равно не то.

Что такое хорошо, а что такое плохо

Многие разработчики всегда считали JavaScript просто «примочкой» к браузеру, эдаким недоязыком, который годится разве что для управления формами и манипулирования DOM-деревом веб-страницы. Некоторые до сих пор думают, что «java» в названии что-то да значит! 🙂 Действительно, язык очень простой. Впрочем, настоящие программисты давно научились творить с его помощью чудеса, предоставив нам потрясающе удобные онлайн-сервисы, которыми мы ежедневно пользуемся. Многие из таких профи пошли дальше и, трезво посмотрев на сам язык и его возможности, особенно по части работы с событиями, решили: а что если на JavaScript написать сервер? Ты получаешь возможность написать на одном и том же языке все части сайта: что серверную часть, что саму клиентскую страничку. Кроме того, JS отлично, просто идеально подходит для разных веб-штучек. Он очень простой и одновременно гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. А главное - это тотальная асинхронность. Это значит, что твой код будет выполняться не последовательно, как в случае с PHP/Perl-скриптами, а именно в тот момент, когда для него будут готовы все данные. Ведь для веба не надо большой вычислительной мощности - большую часть времени сервер ожидает событий вроде получения данных формы, выборки из базы данных или, что еще хуже, ответа на запрос к другому серверу. Обычный РНР-скрипт в такое время простаивает, а значит, простаивает весь поток, не позволяя серверу задействовать его для других пользователей. В такой ситуации не спасает даже Nginx. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Такая функция называется callback, или обработчик событий. Хотя писать действительно сложный код в таком стиле немного неудобно, особенно если твоя функция зависит от нескольких событий сразу, но и для этого уже придумали свои фреймворки, зачастую гораздо более мощные и элегантные, чем все эти РНР/Ruby/Python.

А к чему она вообще, эта асинхронность?

Для примера ограничений последовательного выполнения кода рассмотрим два типовых примера кода на PHP и JavaScript, выполняющих одно и то же. Начнем с любимого PHP:

$result = $db->fetchOne("SELECT user_name FROM user_accounts WHERE id = 1");
echo "Мое имя: " . $result . ";";

В первой строке мы посылаем простой SQL-запрос к БД на выборку имени пользователя, у которого id = 1.Обрати внимание: в этом месте скрипт останавливается, и следующая строка не будет выполнена до того самого момента, пока запрос не будет обработан базой, а результат не возвратится в переменную $result. Да, в нашем примере это тысячные доли секунды, но в реальности и запросы гораздо сложнее, и базы по размеру зачастую составляют гигабайты, и запросов таких может одновременно быть пара тысяч. А теперь попробуем написать код на JS, используя асинхронный стиль:

db.query("SELECT user_name FROM user_accounts WHERE id = 1", function(err, res)
{
if (!err) sys.log("Мое имя: " + res);
});
sys.log("Продолжаем выполнение");

Тут опять же создается запрос к базе данных, однако кроме самого SQL-выражения в запросе передается еще и функция-обработчик (callback). Эта функция будет вызвана именно тогда, когда придет ответ от базы данных, а до этого момента выполнение скрипта ни в коем случае не будет стопориться. Для примера в следующей строке мы просто выводим строку в консоль, чтобы показать, что выполнение сценария продолжается сразу после формирования запроса, не ожидая его завершения. Собственно, в основе любого варианта серверного JavaScript заложена концепция событий и callback’ов, то есть обработчиков событий. Ты можешь описывать собственные события. Тогда ход выполнения приложения будет зависеть от событий, которые возникают в результате активности пользователя на странице («форма заполнена» или «новое сообщение» и т.д.) или генерируются внутри самого сервера (как, например, в случае с обращением к базе данных). Те действия, которые необходимо выполнять в случае наступления событий, описываются внутри функций обработчиков событий.

Движок, вот в чем вопрос

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

Rhino - движок от компании Mozilla, написанный на Java и поддерживающий последнюю 1.7 версию стандарта JS, который к тому же дополняет язык собственными расширениями и объектами. Основным преимуществом движка является работа поверх стандартной JVM, а значит, его можно использовать в любой среде, где работает Java. Другими словами, можно применять современные веб-серверы типа jetty, но при этом писать на любимом JS. Кстати, Rhino применяют на облачном хостинге от Google! А вот с производительностью сложнее. Она зависит, с одной стороны, от движка и применяемых там технологий, вроде JIT-компиляции, и от работы самой Java-машины. Кстати, многие тестеры, которые говорят, что Rhino очень медленный, забывают, что движок имеет два режима работы: интерпретации, когда скрипт каждый раз преобразуется в Java байт-код (аналогично PHP), и компиляции, когда такое преобразование происходит только раз, а потом многократно исполняется. Первый режим выгоден, когда ты отлаживаешь код, который меняется каждую минуту, второй больше подходит для рабочей версии проекта, работающей под нагрузкой.

SpiderMonkey - еще один движок от Mozilla, на этот раз на C. Кстати, это вообще первый в мире движок JS, написанный еще в Netscape - сегодня он открыт и используется в таких популярных продуктах как Firefox, Adobe Acrobat и даже в одном из эмуляторов серверов онлайн-игры Ultima Online. Далее разработчики сильно модифицировали его, добавив компиляцию JS напрямую в ассемблерный код, и переименовали в TraceMonkey - именно этот движок используется в ветке 3.6 Firefox’а. В основном SpiderMonkey используют в ПО, которое написано на С/С++ и нуждается в скриптовом языке. Из известных продуктов: Comet-сервер APE, noSQL БД CouchDB, серверная платформа Jaxer и модуль к Apache mod_js.

Futhark - это движок от Opera, который, кроме браузера, используется в их инновационном сервисе Unite (типа встроенный сервер в каждом браузере), а также на их серверах, обслуживающих мобильный браузер Opera Mini. Жаль, что движок закрыт, и его пока нигде за пределами самой Opera не применяют.

V8 - движок от Google, который используется в Chrome и является основой будущей Chrome OS. Сегодня это самый крутой, быстрый и мощный движок, в котором JS-код напрямую преобразуется в ассемблер целевого процессора, что позволяет обойти по скорости все остальные движки. Кроме этого гугловцы используют множество ухищрений для оптимизации, хранят в памяти скомпилированный код, оптимизируют его на лету (например, удаляют блоки кода, которые по решению компилятора вообще не могут быть задействованы, и т.п.). На базе этого движка построена самая популярная и быстроразвивающаяся серверная платформа - Node.JS .

Node.JS

Вероятно, именно после выхода Chrome разработчики смекнули, что такой быстрый движок можно успешно использовать и на сервере. Первым опытом стал проект V8cgi, который просто позволял писать серверные сценарии, работающие с любым веб-сервером по стандартному протоколу CGI. Дальнейшие эксперименты привели к рождению проекта Node.JS - полностью самостоятельной платформы, включающей, кроме движка, встроенный сервер (HTTP и TCP/UDP/Unix-soket) и базовый набор библиотек, а также предоставляющей полностью асинхронную работу с файлами и сетевыми устройствами.

Проект развивается настолько быстро и активно, что уже сейчас готов к промышленному использованию. Это, в частности, доказывает опыт парней из Plurk (азиатский аналог твиттера), которые полностью перенесли свой comet-сервер, изначально написанный на Java и солидном JBoss Netty, на Node.JS и, по отзывам, сократили потребление памяти буквально на гигабайты. А масштабы у них еще те - более сотни тысяч одновременных соединений.

Запустить HTTP-сервер, способный обрабатывать асинхронно тысячи подключений - это несколько строк кода:

var sys = require("sys"), http = require("http");
http.createServer(function (req, res)
{
res.writeHead(200, {"Content-Type": "text/plain"});
res.end("Hello Worldn");
}).listen(80, "127.0.0.1");
sys.puts("Server running at http://127.0.0.1:80/");

Чтобы запустить сервер, скопируй код в файл example.js и укажи его при запуске демона node:

% node example.js
Server running at http://127.0.0.1:80/

Маленький тест провести очень просто. Можно взять программу Apache Bench - очень простую тулзу для проведения нагрузочного тестирования, и запустить ее: running «ab -n 1000 -c 100 ‘http://127.0.0.1:80/’». Таким образом, бенчмарк будет «обстреливать» сервер тысячами запросов, используя 100 одновременных подключений. На моем ноутбуке сервер выдержал больше 3000 запросов в секунду. Это очень много!

Сам сервер написан на C++ и совсем немножко на ассемблере, однако большая часть библиотек из дистрибутива разработана на JavaScript. В состав базового набора сервера входят только основные функции, остальное оставлено на плечах разработчиков, которые уже написали сотни разных библиотек и фреймворков. Впрочем, молодость проекта дает о себе знать: многих привычных для других решений модулей еще нет, а у многих библиотек текущая версия - 0.0.1, что не придает уверенности в их стабильности. Некоторые тривиальные задачи могут вообще не иметь готового к закачке решения, но бывает и наоборот - количество реализаций, зачастую радикально разных по архитектуре, исчисляется десятками (доступ к базе MySQL, например). Хотя большинство библиотек написано на чистом JavaScript, есть и такие, что требуют компиляции модуля к серверу, что обещает гораздо большую скорость - они просто расширяют стандартный API сервера.

Готовые наработки для серверного JavaScript

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

Narwhal - мощное решение, работающее поверх многих JS-движков. Таким образом, программистам не надо париться по поводу различия различных серверов - они могут просто писать код.

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

JSGI (JavaScript gate interface) - разработан специальный протокол взаимодействия связи веб-демона и серверных сценариев на JavaScript. Увы, спецификацию пока полностью поддерживает только проект Rhino в окружении сервера jetty.

Особенности Node.JS

Основной особенностью Node, кроме полной асинхронности, является его однопоточная модель. Другими словами, все операции выполняются в одном и том же потоке ОС, даже если у твоего сервера тысяча одновременных пользователей. Правда, доступно создание дочерних процессов и низкоуровневое управление исполнением скриптов (загрузка, компиляция, работа с ассемблерным кодом, исполнение). Для реализации многопоточности и задействования всех ядер современных процессоров рекомендуется просто загружать несколько копий приложения, но можно взять на вооружение WebWorker из стандарта HTML5 и распределить работу приложения по нескольким дочерним процессам. Не думай, что раз нет многопоточности - это тормоз и отстой. Вспомни, что веб-приложение делает полезную работу очень быстро, а большую часть времени просто ожидает чего-то (данных от базы, от memcached’а или новомодной NoSQL-базы), либо просто держит в памяти открытые соединения для Comet’а, поэтому в одном потоке можно обработать и десяток тысяч, не прибегая к кластеризации.

Второй особенностью архитектуры Node является событийность. Почти каждая операция имеет коллбэки, генерирует событие, а пользователю доступен объект EventEmiter, через который можно буквально одной строкой генерировать свои события (это несложно, ведь событие - это просто строка с названием, а также список параметров, которые передаются в обработчик).

Сам по себе Node построен вокруг EventLoop - глобального цикла обработки событий, который на каждом тике проверяет, готовы ли данные для какого-либо из определенных пользователем коллбэков. Если данные есть, начинается выполнение кода. Если не осталось больше кода - ожидаем следующего вызова. Цикл выполняется вне JS, а в самом движке, написанном на C, вследствие чего это происходит очень и очень быстро (порядка сотен тысяч раз в секунду). Что-то типа бесконечного цикла. В дополнение к этому в сервер встроен очень эффективный сборщик мусора (GC), поэтому даже тысячи подключений не вызывают переполнения памяти и падения сервера. Node.JS обладает встроенной родной системой работы с событиями.

Простейший Steaming-сервер

Попробуем написать простой, но в тоже время полезный пример, который в реальном времени будет выдавать пользователю полезную информацию без перезагрузки страницы. Вот идея для нашего приложения - брать новые данные, которые добавляются в текстовый лог, и выводить их в реальном времени на веб-странице:

var sys = require("sys"), net = require("net"), spawn = require("child_process").spawn, http = require("http");
sys.puts("nMy process PID: " + process.pid + "n");
var tail = spawn("tail", ["-f", "/var/log/nginx/access.log"]);
// указываем названия логфайла
sys.puts("Start tailing");
tail.stdout.addListener("data", function (data)
{ sys.puts(data);
//дублируем себе на консоль
});
http.createServer(function(req,res)
{
res.sendHeader(200,{"Content-Type": "text/plain"});
tail.stdout.addListener("data", function (data) { res.write(data); });
}).listen(80);

С помощью функции spawn() мы создаем дочерний процесс утилиты tail, которая, собственно, и занимается тем, что считывает новые данные, которые появляются в логфайле. Процесс запускается только раз во время старта сервера. Собственно, наша задача - отлавливать моменты, когда команда tail будет выводить новые данные из логфайла и транслировать вывод на веб-страницу каждому подключившемуся клиенту. Для этого мы будем следить за возникновением события data (появлением новых данных) для переменной, к которой запущен процесс утилиты tail, и выводить их на страницу с помощью команды write(). Таким образом, соединение будет оставаться открытым для каждого HTTP-запроса. Вот и все. Следить за активностью процесса не так просто для обычного веб-приложения, но ничего не стоит для неблокируемой архитектуры Node.JS и логики выполнения, основанной на событиях. Нам остается только запустить скрипт: «node tail.js error.log» и открыть в браузере http://localhost:80. На странице будут отображаться все сообщения, которые появляются в логфайле error.log.

Вот и сказочке конец

Сейчас, выбирая на чем бы таком написать очередное web 2.0 приложение, где не только красивый клиентский код, но и что-то надо делать на сервере, тебя парит одна грустная мысль о том, что все уже изобрели и написали до тебя. Те же языки, что и десять лет назад, те же библиотеки, протоколы и сервера. РНР уже ого сколько лет, Perl так вообще седой, Python у всех на слуху, а Ruby успел надоесть. Писать для веба стало рутиной - посмотри, как твои друзья сидят и думают, что же сделать с 25-мегабайтным монстром Zend-framework. А тебе хочется что-то нового, быть на острие прогресса, создавать то, на чем потом будут писать все, а сейчас знают только увлеченные хакеры и ищущие себя дзен-программеры? Посмотри на JavaScript в сервере, он просто создан для этого. Очень простой, мощный, еще не погрязший в тонне библиотек и фреймворков. Задачи, которые на РНР не решить вообще, на базе Node.JS решаются буквально десятком строк. И, возможно, именно такое программирование, наконец, принесет утраченное чувство наслаждения от разработки!

WWW

• Материалы по NodeJS: groups.google.com/group/nodejs
• Русскоязычный сайт и форум: forum.nodejs.ru
• Информация о серверном JS: en.wikipedia.org/wiki/Server-side_JavaScript
• Хороший мануал для начинающих по Node.JS: www.slideshare.net/the_undefined/nodejs-a-quick-tour
• Презентациявведение по Node.JS: nodejs.org/jsconf.pdf

INFO

Большинство, если не все, библиотеки и проекты на Node.JS сосредоточены на Github, поэтому если нет какого-то модуля, нужного тебе, ищи его там.

• Перевод

В 2009-м платформа Node.js сделала свои скромные первые шаги в бескрайнем мире разработки бэкендов. Это была была первая состоявшаяся попытка использования JavaScript в серверных приложениях. Сегодня будет крайне затруднительно найти веб-разработчика, который не слышал о Node. Но нельзя сказать, что существование Node было безоблачным. Эта платформа пережила раскол сообщества, была предметом форумных войн и многих довела до отчаяния.

Возможно, вы думаете, что подобные заявления звучат слишком уж напыщенно. Однако, попробуйте поискать в Google, и вы столкнётесь с неистощимым источником бесконечных споров . Среди рассуждений не в пользу Node, которые могут вам встретиться, есть, например, такие, которые, вопрошая о том, что случилось с аксиомой об использовании лучшего из имеющихся инструментов для решения некоей задачи, указывают, что JS и рядом не стоял с правильным серверным инструментарием. критические замечания о JS, вроде «Callback hell is real», призывающие поверить в реальность ада коллбэков, звучат как строчки из стихотворения. Некоторые из критиков Node выражаются более прямо и однозначно: «Node - это раковая опухоль».

Полагаю, настало время восстановить истинное положение вещей, расставить все точки над «i» в том, что касается платформы Node.js и JavaScript в роли языка серверной разработки. Сегодня мы поговорим о современном состоянии и развитии Node.js, о наиболее удачных вариантах использования этой платформы, о её ограничениях, и о технологиях, созданных на её основе.

Современное состояние Node.js как серверной платформы

А именно, это среда выполнения JavaScript, построенная на базе JS-движка V8 , разработанного Google и применяемого в Google Chrome. Node.js использует неблокирующую модель ввода-вывода, управляемую событиями, которая делает эту платформу простой и эффективной.

В начале этого материала Node показан как прямо-таки кошмар программиста. Однако, эта платформа не случайно стала весьма популярной. Тут мы не станем опираться на голословные утверждения. Лучше взглянем на факты. А именно, свежее исследование Stack Overflow показывает, что Node.js - это, на сегодняшний момент, самая популярная среди разработчиков технология.

Node.js не только совершил революцию в серверной разработке, но благодаря ему сделан вклад и в производительность клиентских приложений, так как к развитию V8 были привлечены серьёзные силы. Кроме того, он играет заметную роль в расширении всей экосистемы JavaScript и в совершенствовании современных JS-фреймворков, таких, как Angular , React или Vue .

С течением времени Node смог опровергнуть предрассудки ранних дней. Вот некоторые из них.

JavaScript-код для Node.js печально известен сложностью отладки.

Для отладки серверных JS-приложений можно использовать те же самые методики, которые применяются для отладки клиентского кода, применяя node-inspector , где собраны средства инструментов разработчика Chrome.

Node нельзя использовать для разработки серверных приложений корпоративного класса.

Это утверждение тоже не соответствует действительности. На базе Node можно создавать корпоративные системы. Сложность заключается лишь в том, что в нём имеется не особенно много встроенных средств, упрощающих создание подобных систем. Однако, заметные игроки IT-рынка используют Node в качестве корпоративной веб-платформы. Среди них - Netflix. PayPal, Yahoo!, Walmart.

JavaScript - это динамический язык, поэтому, работая на нём, нельзя использовать нечто вроде статической проверки типов при компиляции.

Это правда. Однако, в экосистеме JS появились средства вроде TypeScript и Flow, которые нацелены на работу с типами в JS, что позволяет повысить стабильность и предсказуемость программ, упростить отладку. В этой сфере можно воспользоваться и возможностями Closure Compiler от Google.

JavaScript не создавался как язык для серверной разработки.

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

На самом деле, этот список можно продолжать и продолжать.

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

Сценарии применения Node

▍Преимущества и общие характеристики

• Весьма вероятно, что клиентские части ваших веб-приложений написаны на JavaScript. В этом случае универсальность кода в применяемом стеке технологий - это важный плюс использования JS и на сервере, о котором стоит помнить.
• Инструменты вроде webpack помогают в повторном использовании кода и на клиенте, и на сервере, что ведёт к его единообразию на всех уровнях системы.
• Применяя JS на клиенте и на сервере , можно создавать веб-приложения, которые могут рендериться и в браузере, и на сервере . При этом такие системы обычно работают весьма чётко и понятно. Полагаю, это - просто потрясающе.
• Появление в Node конструкции async/await полностью изменило подход к написанию асинхронного кода. Теперь такой код напоминает обычный синхронный код, и по внешнему виду, и по поведению. Механизм async/await поддерживается в Node начиная с версии 7.6 . Он, в частности, является решением печально известной проблемы ада коллбэков .

Скажем, вам нужны инструменты для кодирования видео. Для того, чтобы оснастить ими свой проект, написанный на JavaScript, вам не придётся искать какие-то малораспространённые таинственные библиотеки для Node. Вы вполне сможете воспользоваться проверенными инструментами, наладив взаимодействие с ними из Node. Или, например, если имеется некая библиотека на Python, выполняющая необходимые вам сложные вычисления, специально для работы с ней можно запустить микросервис и обращаться к соответствующим функциям этой библиотеки через REST API.

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

▍Сценарий №1. Приложения реального времени

Время, необходимое этим приложениям для выполнения тех или иных действий, можно охарактеризовать, с точки зрения пользователя, словами «немедленно» и «сейчас» . Для нормальной работы таких приложений система, на которой они основаны, должна обеспечивать очень высокую скорость отклика на действия пользователя и низкий уровень задержек. Node отвечает этим требованиям.

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

▍Сценарий №2. Одностраничные приложения

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

▍Сценарий №3. Масштабируемость

Даже название предмета нашего разговора, «node» акцентирует внимание на возможности построения систем из множества небольших распределённых вычислительных узлов, которые могут обмениваться друг с другом данными.

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

Однако, надо отметить, что подобным возможностям масштабирования сопутствуют и определённые сложности. И, если потерять бдительность, Node.js может стать… опасным.

Ограничения Node.js

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

В случае с другими языками, вроде Ruby, и широко известного фреймворка Ruby on Rails, например, в ходу идея, которая заключается в преимуществе соглашений над конфигурированием системы. Эти традиционные фреймворки буквально ведут разработчика за руку, показывая ему правильный, безопасный путь решения типичных задач.

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

Даже создатель Node.js, Райан Даль , в итоге, перед переходом к другим проектам, осознал ограничения системы. Он высказался на этот счёт весьма однозначно:

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

Ранее упомянутые предубеждения, касающиеся Node, были справедливы до определённого момента не такого уж и длинного жизненного пути Node, и они, до некоторой степени, всё ещё - не пустой звук. Node достаточно повзрослел и вырос, его слабые стороны, при необходимости и наличии времени, вполне можно обойти. А инструменты, разработанные сообществом, позволяют создать на базе Node.js практически всё, что угодно.

Популярные вспомогательные средства для серверной разработки на JS

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

Вот несколько популярных современных серверных JS-фреймворков:

• Express.js был и всё ещё является самым популярным Node.js-фреймворком . Он быстр, компактен, не навязывает разработчику жёстких архитектурных решений. В основе его стремительного развития лежит простота и понятность. Возможно, он идеологически ближе всех остальных инструментов к идеям, лежащим в основе, Node, следуя которым он представляет собой легковесную модульную систему.
• Meteor , с другой стороны, использует чистый JavaScript и Node.js внутри довольно-таки масштабной конструкции. Meteor и сам по себе - это целая экосистема, которая может подойти для разработки более сложных серверных приложений. Однако, использование Meteor может усложниться, если нужно что-то, что не встроено в систему.
• Sails.js - это MVC-фреймворк реального времени. Он был разработал для имитации шаблона MVC на платформе Ruby on Rails, но при этом подразумевал поддержку требований современных веб-приложений. Работает это всё благодаря API, которые управляются данными, при наличии масштабируемой, сервис-ориентированной архитектуры.

  Полагаю, самое главное, что мне хотелось сделать - так это показать, что между безапеляционными «да» и «нет», которые можно встретить во многих рассуждениях о Node и о JS как о серверном языке, если обширная область «может быть».

  И, нравится это кому-нибудь или нет, интерес к Node постоянно растёт.

  

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

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

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

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

  Теги: Добавить метки

На сервере (IIS) по следующим причинам:

Передача навыков - мы хотели бы использовать JavaScript и jQuery на сервере и не использовать, например, VB Script./классический asp. .Net framework/Java и т. Д. Исключается из-за этого.

Улучшены параметры поиска/доступности. Мы хотели бы иметь возможность использовать jQuery в качестве системы шаблонов, но это небезопасно для поисковых систем и пользователей с отключенным - если мы не можем выборочно запускать этот код на сервере.

В IIS и Windows Server есть значительные инвестиции, поэтому изменение не является вариантом.

Я знаю, что вы можете запускать jScript в IIS с помощью хоста Windows Script, но я не уверен в масштабируемости и процессе, связанном с этим. Я также не уверен, что это будет иметь доступ к DOM.

Вот диаграмма, которая, надеюсь, объясняет ситуацию. Мне было интересно, если кто-нибудь сделал что-нибудь подобное?

EDIT: я не ищу критика в веб-архитектуре, я просто хочу знать, есть ли какие-либо возможности для манипулирования DOM страницы, прежде чем она будет отправлена ​​клиенту, используя javascript. Jaxer - один из таких продуктов (без IIS). Спасибо.

7 ответы

Идея повторного использования клиентского JS на сервере может казаться соблазнительной, но я не уверен, что сам jQuery будет готов к запуску в серверной среде.

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

Кроме того, как отметил Cheeso, Active Server Pages - очень устаревшая технология, в начале века она была заменена на ASP.Net Microsoft. Раньше я использовал систему устаревания с использованием ASP 3.0 более года, и это было больно. Самое замечательное времяпрепровождение - отладка: вы вряд ли найдете что-нибудь для этой цели сегодня и должны будете ослабить красивые ошибки, как в журнале IIS:

ошибка "800a9c68"
Определенная пользователем или объектная ошибка

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

JScript работает в IIS с помощью ASP. Активные серверные страницы.
Он был впервые доступен в 1996 году.

В конце концов ASP.NET был представлен как преемник. Но ASP по-прежнему поддерживается.

Однако для DOM-страницы нет DOM.

Возможно, вам придется немного пересмотреть свою архитектуру.

Я думаю, что единственные жизнеспособные решения, которые вы, вероятно, найдете в любом месте рядом с готовыми к работе, включают в себя размещение IIS перед Java. Есть две браузерные среды, которые я знаю о закодированных для Java:

Если вы хотите что-то чистое-IIS/MS, я думаю, что ваше наблюдение за хостом WindowsScript и/или чем-то вроде полузаброшенного JScript.NET, вероятно, примерно так же близко, как и вы, а также порт (который вы, вероятно, придется начинать) с чем-то вроде Env-js или HTMLUnit.

Кроме того, я не знаю, видели ли вы список решений на стороне сервера в Википедии:

Наконец... вы, вероятно, могли бы написать пригодную для использования jQuery-подобную библиотеку на любом языке, на котором уже есть какая-то библиотека DOM и первоклассные функции (или, если это невозможно, eval). См. Например, pQuery для Perl (http://metacpan.org/pod/pQuery). Это даст вам преимущества стиля jQuery для манипулирования документами. Передача навыков велика, и у JavaScript есть замечательное слияние очень приятных функций, но, с другой стороны, разработчики, которые заботятся о том, чтобы изучать несколько языков, также великолепны, а - не единственный приятный язык.

Что именно вы подразумеваете под