Своей притягательностью платформа Node отчасти обязана пропускной способности (количество обслуживаемых запросов в секунду). Сравнительные тесты схожих программ, например Apache и Node, показывают фантастический выигрыш в производительности.
Один из популярных эталонных тестов - следующий
простой НТТР-сервер, который всего лишь возвращает сообщение «HelloWorld»,
читаемое из памяти:
var http = require( http');.createServer(function (req, res) {.writeHead(200, {'Content-Type': text/plain'});.end('Hello World\n');
}).listen(8124,
"127.0.0.1");.log( Server running at #"774113.files/image001.gif">
Здесь показано гипотетическое приложение drawapp. Если каталог node_modules расположен так, как показано на рисунке, то любой модуль внутри drawapp может получить доступ к express следующим образом:
express = require( express');
Однако те же самые модули не смогут добраться до модуля qs, скрытого внутри каталога node_modules, являющегося частью самого каркаса Express. Просмотр каталогов node_modules, содержащих искомый модуль, производится вверх по иерархии файловой системы, без захода в дочерние каталоги.
Аналогично: если установить модуль в каталог lib/node_modules, то он будет доступен из draw.js и svg.js, но недоступен из index.js. Как и раньше, поиск происходит вверх от текущего каталога, а не вглубь него.
При обходе каталогов node_modules Node
останавливается, как только найдет искомый модуль. Так, если ссылка встречается
в файле draw,js или svg.js, то будут просмотрены следующие каталоги:
/home/david/projects/drawapp/lib/node_modules
/home/david/projects/drawapp/node_modules
/home/david/projects/node_modules
/home/david/node_modules
/home/node_modules
/node_modules
Каталог node_modules играет важнейшую роль, позволяя системе управления пакетами выпутаться из лабиринта конфликтующих версий. Вместо того чтобы помещать все модули в одно место и медленно сходить с ума, пытаясь разрешить зависимости от конфликтующих номеров версий, мы можем завести несколько каталогов node_modules и при необходимости складывать конкретные версии в конкретное место. Разные версии одного модуля могут находиться в разных каталогах node_modules, и при условии, что эти каталоги расположены правильно относительно друг друга, никаких конфликтов не возникнет.
Пусть, например, мы написали приложение, в
котором используется модуль forms (https://github.com/caolan/forms) для
построения форм, и, когда у вас уже накопились сотни форм, авторы модуля внесли
в него несовместимые изменения. Переделывать и заново тестировать все формы
сразу вам не хочется, лучше делать это постепенно. Для этого надо будет создать
в приложении два каталога, организовать в каждом свой подкаталог node_modules и
поместить в них разные версии модуля forms. Затем, по мере перевода очередной
формы на новый модуль forms, ее код перемещается в каталог, где находится новая
версия.
.4 Системные модули в каталогах, перечисленных в
массиве require.paths
При поиске каталогов node_modules Node не ограничивается деревом приложения. Алгоритм доходит до корня файловой системы, поэтому можно создать каталог /node_modules и организовать в нем глобальный репозиторий модулей. Именно здесь будет завершаться поиск модуля, не найденного ни в каком другом месте.
Но Node предоставляет и еще один механизм, основанный на переменной require,paths. Это массив имен каталогов, в которых следует искать модули.
Приведем пример:
$ node
> require.paths;
["/home/david/.node_modules",''/home/david/.node_libraries", "/usr/local/lib/node"]
Для заполнения массива require,paths используется переменная окружения NODE_PATH:
$ export NODE_PATH=/usr/lib/node
$ node
> require.paths;
["/usr/lib/node","/home/david/.node_libraries","/usr/local/lib/node”]
>
Раньше в программах для Node часто применялась следующая идиома для добавления новых элементов в массив require.paths:require.paths.push(__dirname). Однако теперь она не рекомендуется, потому что, как выяснилось, является источником путаницы. Хотя так делать можно и даже еще остались модули, в которых эта идиома встречается, но смотрят на ее использование с большим неодобрением. Если несколько модулей помещают каталоги в require.paths, то результаты непредсказуемы.
В большинстве случаев рекомендуется устанавливать модули в каталоги node_modules.
Составные модули - модули-каталоги
Составной модуль может включать несколько внутренних модулей, файлы данных, файлы шаблонов, документацию, тесты и прочее. Все это можно поместить в хорошо продуманную структуру каталогов, которую Node будет рассматривать как модуль, и загружать командой require('moduleName'). Для этого следует добавить в каталог файл модуля index.js или файл с именем package.json. Файл package.json должен содержать данные, описывающие модуль, в формате, очень похожем на формат файла package.json, используемого менеджером пакетов npm (см. ниже). В обоих случаях для совместимости с Node достаточно очень небольшого набора полей, распознаваемых npm.
Точнее, Node распознает следующие поля в файле
package.json:
{ name:
"myAwesomeLibrary",: "./lib/awesome.js" }
При таком файле package.json
команда require('myAwesomeLibrary')
найдет этот каталог и загрузит файл
/path/to/node_modules/myAwesomeLibrary/lib/awesome.js
Если файла package.json нет, то Node будет
вместо него искать файл index.js, то есть загрузит файл:
/path/to/node_modules/myAwesomeLibrary/index.js
В любом случае (index.js или package.json) реализовать составной модуль, содержащий внутренние модули и другие файлы, несложно. Если вернуться к рассмотренной выше структуре пакета Express, то мы увидим, что некоторые модули пользуются относительными идентификаторами для ссылки на другие модули в пакете, а для включения модулей, разработанных кем-то другим, можно воспользоваться каталогом node_modules.
Менеджер пакетов для Node (npm)- это система управления и распространения пакетов для Node, ставшая стандартом де-факто. Концептуально она похожа на такие инструменты, как apt-get (Debian), rpm/yum (Redhat/Fedora), MacPorts (Mac OS X), CPAN (Perl) и PEAR (PHP). Ее задача - обеспечить публикацию и распространение пакетов Node через Интернет с помощью простого интерфейса командной строки. Npm позволяет быстро находить пакеты для решения конкретной задачи, загружать и устанавливать их, а также управлять уже установленными пакетами.
В npm определен формат пакета для Node, основанный на спецификации CommonJS.
Формат npm-пакетапакет представляет собой
структуру каталогов, описанную в файле package.json. Именно так мы выше
определили составной модуль, отличие только в том, что npm распознает
значительно больше полей, чем Node. Исходной точкой для определения формата
package,json для npm послужила спецификация CommonJS Packages/1.0. Получить
документацию по структуре файла package,json позволяет следующая команда:
$ npm help json
Простейший файл package,json выглядит следующим
образом:
{ name: "packageName",: "1.0",: "mainModuleName",: {
"mod1”: "lib/mod1",
"mod2": "lib/mod2"
}
}
Файл представлен в формате JSON, c. которым вы как программист на JavaScript, должно быть, встречались уже сотни раз.
Наиболее важны поля name и version. Значение
name подставляется в URL-адреса и названия команд, поэтому выбирать его следует
с учетом безопасности в этих контекстах. Если мы соберемся опубликовать пакет в
общедоступном репозитории npm-пакетов, то должны проверить, не занято ли
выбранное имя. Для этого можно обратиться к сайту #"774113.files/image002.gif">
Для вычисления больших чисел Фибоначчи все равно
требуется много времени, но сервер не блокируется и может обрабатывать другие
запросы. В этом легко убедиться, открыв страницу в нескольких вкладках
браузера. В одной вкладке запросив вычисление большого числа Фибоначчи, а во
второй выполнив другие запросы. Теперь сервер не впадает в глубокую
задумчивость, а возвращает результаты.
Заключение
Этот проект - прекрасная отправная точка, с которой
можно начать путешествие в увлекательный мир разработки веб-приложений для
Node.js. При желании на практике можно научиться пользоваться серверным и
клиентским объектами HTTP, каркасами Connect и Express, освоить алгоритмы
асинхронного выполнения и узнать, как работать с базами данных на основе SQL и
с MongoDB. А Также познакомиться с применяемой в Node.js системой организации
модулей на основе спецификации CommonJS, которая позволяет реализовать
представительное подмножество технологии объектно-ориентированного
проектирования.
Список использованной литературы