Разработка Web-приложения с использованием JavaScript каркаса Node.js
Министерство
образования и науки РФ
Федеральное
государственное бюджетное образовательное учреждение высшего профессионального
образования
"Рязанский
государственный радиотехнический университет"
Курсовая
работа
по
дисциплине: «Интернет-технологии»
на
тему: «РазработкаWeb-приложения с использованием JavaScript каркаса Node.js»
Выполнил: студент 1
курса,
группы 345М
Симаков А.Ю.
Проверил: доцент
Бакулев А.В.
Рязань
2013
Содержание
Введение
. Что
такое NODE?
.1 Что
позволяет делать Node?
.2 Почему
имеет смысл использовать Node?
.3 Архитектура:
потоки или асинхронный ввод/вывод с управлением по событиям
.4 Производительность
и использование процессора
.5 Использование
серверов, экономия затрат и экологичный Интернет
. Характеристики
NODE
.1 Системные
требования
.2 Запуск
Node-серверов на этапе инициализации системы
.3 Использование
всех процессорных ядер в многоядерной системе
. Модули
Node
.1 Как
Node ищет модули, затребованные в require('module')?
.2 Менеджер
пакетов для Node (npm)
. Хранение
и выборка данных
.1 Движки
сохранения данных для Node
.2 SQLite3
- облегченная встраиваемая база данных на основе SQL
.3 Mongoose
- интерфейс между Node и MongoDB
. Практический
пример на основе продолжительных вычислений (числа Фибоначчи)
Заключение
Список
использованной литературы
node сервер приложение данный
Введение
(другое название - Node,js)- это недавно
появившаяся платформа, которая выводит язык JavaScript за пределы браузера и
позволяет использовать его в серверных приложениях. В основе платформы лежит
исключительно быстрый движок JavaScript, заимствованный из браузера Chrome, V8,
к которому добавлена быстрая и надежная библиотека асинхронного сетевого
ввода/вывода. Основной упор в Node делается на создании высокопроизводительных,
хорошо масштабируемых клиентских и серверных приложений для «веб реального
времени».
Эту платформу разработал Райан Дал (RyanDahl) в
2009 году, после двух лет экспериментирования с созданием серверных
веб-компонентов на Ruby и других языках. В ходе своих исследований он пришел к
выводу, что вместо традиционной модели параллелизма на основе потоков следует
обратиться к событийно-ориентированным системам. Эта модель была выбрана за
простоту (хорошо известно, что многопоточные системы трудно реализовать правильно),
за низкие накладные расходы, по сравнению с идеологией «один поток на каждое
соединение», и за быстродействие. Цель Node - предложить «простой способ
построения масштабируемых сетевых серверов». При проектировании за образец были
взяты такие системы, как EventMachine (Ruby) и каркас Twisted (Python).
. Что такое NODE?
- это захватывающая новая платформа для
разработки веб-приложений, серверов приложений, произвольных сетевых серверов и
клиентов, да и вообще для программирования. Она спроектирована так, чтобы
обеспечить высочайшую масштабируемость сетевых приложений - за счет хитроумного
сочетания асинхронного ввода/вывода, использования JavaScript на стороне
сервера, изобретательного использования анонимных функций JavaScript и
однопоточной событийно-ориентированной архитектуры.
Принятая в Node модель принципиально отличается
от распространенных платформ для построения серверов приложений, в которых
масштабируемость достигается за счет многопоточности. Утверждается, что
благодаря событийно-ориентированной архитектуре снижается потребление памяти,
повышается пропускная способность и упрощается модель программирования. Сейчас
платформа Node быстро развивается, и многие считают ее привлекательной
альтернативой традиционному подходу к разработке веб-приложений - на базе
Apache, РНР, Python и т. п.
В основе Node лежит автономная виртуальная
машина JavaScript с расширениями, делающими ее пригодной для программирования
общего назначения с упором на разработку серверов приложений. Платформу Node не
имеет смысла напрямую сравнивать ни с языками программирования, которые обычно
используются для создания веб-приложений (PHP/Python/Ruby/Java и прочие), ни с
контейнерами, реализующими протокол HTTP (Apache/Tomcat/Glassfish ит. д.). В то
же время многие считают, что потенциально она может заменить традиционные стеки
веб-приложений.
В основе реализации лежит цикл обработки событий
неблокирующего ввода/вывода и библиотеки файлового и сетевого ввода/вывода,
причем все это построено поверх движка V8 JavaScript (заимствованного из
веб-браузера Chrome). Библиотека ввода/вывода обладает достаточной общностью
для реализации любого протокола на базе TCP или UDP: DNS, HTTP, IRC, FTP и др.
Но хотя она поддерживает разработку серверов и клиентов произвольного
протокола, чаще всего применяется для создания обычных веб-сайтов, где заменяет
Apache/PHP или Rails.
.1 Что позволяет делать Node?
- платформа для написания JavaScript-приложений
вне веб-браузера. Это не тот JavaScript, с которым все мы знакомы по опыту
работы с браузерами. В Node не встроена ни объектная модель документа (DOM), ни
какие-либо ещё возможности браузера. Именно язык JavaScript в сочетании с
асинхронным вводом/выводом делает Node мощной платформой для разработки
приложений. Но вот для чего Node непригодна, так это для разработки
персональных приложений с графическим интерфейсом пользователя (ГИП). На
сегодняшний день в Node нет встроенного эквивалента Swing (или SWT). Нет и
подключаемой библиотеки ГИП для Node, и внедрить Node в браузер тоже нельзя.
Если бы для Node существовала библиотека ГИП, то на этой платформе можно было
строить и персональные приложения. Недавно появилось несколько проектов по
созданию интерфейса между Node и GTK, итогом которых должна стать
кросс-платформенная библиотека ГИП. В состав движка V8, используемого в Node,
входят API-расширения, позволяющие писать на C/C++ код для расширения
JavaScript или интеграции движка с платформенными библиотеками.
Помимо встроенного умения исполнять код на
JavaScript, включенные в состав дистрибутива модули предоставляют и другие
возможности:
утилиты командной строки (для включения в
скрипты оболочки);
средства написания интерактивных консольных
программ (цикл «чтение - выполнение - печать»);
великолепные функции управления процессами для
наблюдения за дочерними процессами;
объект Buffer для работы с двоичными данными;
механизм для работы с сокетами TCP и UDP с
полным комплектом обратных вызовов в ответ на события;
поиск в системе DNS;
средства для создания серверов и клиентов
протоколов HTTP и HTTPS, построенные на основе библиотеки ТСР-сокетов;
средства доступа к файловой системе;
встроенная рудиментарная поддержка автономного
тестирования с помощью утверждений.
Сетевой слой Node находится на низком уровне, но
работать с ним все равно просто. Например, модули HTTP позволяют реализовать
HTTP-сервер (или клиент), написав всего несколько строк кода, но, тем не менее,
на этом уровне программист работает очень близко к реальным запросам по
протоколу и может точно указать, какие HTTP-заголовки следует включать в ответ на
запрос. Если программист на РНР обычно не интересуется заголовками, то для
программиста на Node они существенны.
Иными словами, написать на Node HTTP-сервер
очень просто, но типичному разработчику веб-приложений нет нужды работать на
таком низком уровне. Например, кодируя на РНР, программист предполагает, что
Apache уже присутствует, так что реализовывать серверную часть стека ему не
нужно. Сообщество, сложившееся вокруг Node, создало широкий спектр каркасов для
разработки веб-приложений, в том числе Connect, которые позволяют быстро
сконфигурировать HTTP так, чтобы предоставлялось все, к чему мы привыкли, -
сеансы, куки, обслуживание статических файлов, протоколирование и т.д. - и
пусть разработчик занимается бизнес-логикой приложения.
.2 Почему имеет смысл использовать Node?
Язык JavaScript очень популярен благодаря
присутствию в любом веб-браузере. Он ни в чем не уступает другим языкам, но при
этом поддерживает многие современные представления о том, каким должен быть
язык программирования. Благодаря широкому распространению имеется немало
опытных программистов на JavaScript.
Это динамический язык со слабо типизированными,
динамически расширяемыми объектами, которые неформально объявляются по мере
необходимости. Функции в нем являются полноценными объектами и обычно
используются в виде анонимных замыканий. Это делает JavaScript более мощным
языком, по сравнению с некоторыми другими, часто применяемыми для разработки
веб-приложений. Теоретически наличие подобных возможностей должно повышать
продуктивность программистов. Но споры между сторонниками динамических и
статических языков, а также строгой и слабой типизации до сих пор не утихли и
вряд ли когда-нибудь утихнут.
Один из основных недостатков JavaScript -
Глобальный Объект. Все переменные верхнего уровня «сваливаются» в Глобальный
Объект, и при использовании одновременно нескольких модулей это может привести
к неуправляемому хаосу. Поскольку веб-приложения обычно состоят из множества
объектов, возможно, создававшихся разными организациями, то может возникнуть
опасение, будто программирование для Node сродни хождению по минному полю,
нашпигованному конфликтующими между собой глобальными объектами. Однако это не
так. На самом деле в Node используется система организации модулей CommonJS, а
это означает, что локальные переменные некоторого модуля так и будут локальными
в нем, пусть даже выглядят как глобальные. Такое четкое разграничение между
модулями решает проблему Глобального Объекта.
Использование единого языка программирования на
сервере и на клиенте давно уже было мечтой разработчиков для веб. Своими
корнями эта мечта уходит в период становления Java, когда апплеты
представлялись клиентским интерфейсом к написанным на Java серверным
приложениям, a JavaScript первоначально виделся как облегченный скриптовый язык
взаимодействия с апплетами. Но что-то на этом пути не сложилось, и в результате
не Java, a JavaScript стал основным языком на стороне клиента-браузера. С
появлением Node мы, наконец, сможем реализовать мечту - сделать JavaScript
языком, используемым по обе стороны веб - на стороне клиента и сервера.
У единого языка есть несколько потенциальных
плюсов:
одни и те же программисты могут работать над
обеими сторонами приложения;
код проще переносить с сервера на клиент и
обратно;
общий для клиента и сервера формат данных
(JSON);
общий программный инструментарий;
общие для клиента и сервера средства
тестирования и контроля качества;
на обеих сторонах веб-приложения можно
использовать общие шаблоны представлений;
общий язык общения между группами, работающими
над клиентской и серверной частью.упрощает реализацию этих (и других)
достоинств, предлагая основательную платформу и активное сообщество
разработчиков.
Говорят, что именно благодаря асинхронной
событийно-ориентированной архитектуре Node демонстрирует столь высокую
производительность. Так и есть, только к этому надо добавить еще
стремительность движка V8 JavaScript. В традиционной модели сервера приложений
параллелизм обеспечивается за счет использования блокирующего ввода/вывода и
нескольких потоков. Каждый поток должен дожидаться завершения ввода/вывода,
перед тем как приступить к обработке следующего запроса.
В Node имеется единственный поток выполнения,
без какого-либо контекстного переключения или ожидания ввода/вывода. При любом
запросе ввода/вывода задаются функции обработки, которые впоследствии
вызываются из цикла обработки событий, когда станут доступны данные или
произойдет еще что-то значимое. Модель цикла обработки событий и обработчика
событий - вещь распространённая, именно так исполняются написанные на
JavaScript скрипты в браузере. Ожидается, что программа быстро вернет
управление циклу обработки, чтобы можно было вызвать следующее стоящее в
очереди задание. Чтобы повернуть наши мысли в нужном направлении, Райан Дал (в
презентации «Cincode Node») спрашивает, что происходит при выполнении такого
кода:
result = query('SELECT * from db);
Разумеется, программа в этой точке
приостанавливается на время, пока слой доступа к базе данных отправляет запрос
базе, которая вычисляет результат и возвращает данные. В зависимости от
сложности запроса его выполнение может занять весьма заметное время. Это плохо,
потому что пока поток простаивает, может прийти другой запрос, а если заняты
все потоки, то запрос будет просто отброшен. Расточительно это как-то. Да и
контекстное переключение обходится не бесплатно; чем больше запущено потоков,
тем больше времени процессор тратит на сохранение и восстановление их
состояния. Кроме того, стек каждого потока занимает место в памяти. И просто за
счет асинхронного событийно-ориентированного ввода/вывода Node устраняет
большую часть этих накладных расходов, привнося совсем немного собственных.
Часто рассказ о реализации параллелизма с
помощью потоков сопровождается предостережениями типа «дорого и чревато
ошибками», «ненадежные примитивы синхронизации в Java» или «проектирование
параллельных программ может оказаться сложным, и не исключены ошибки» (фразы
взяты из результатов, выданных поисковой системой). Причиной этой сложности
являются доступ к разделяемым переменным и различные стратегии предотвращения
взаимоблокировок и состязаний между потоками. «Примитивы синхронизации в Java»
- один из примеров такой стратегии, и, очевидно, многие программисты считают,
что пользоваться ими трудно. Чтобы как-то скрыть сложность, присущую
многопоточному параллелизму, создаются каркасы типа java.util.concurrent, но
все равно некоторые считают, что попытка упрятать сложность подальше не делает
проблему проще.призывает подходить к параллелизму по-другому. Обратные вызовы
из цикла обработки событий - гораздо более простая модель параллелизма, как для
понимания, так и для реализации.
Чтобы пояснить необходимость асинхронного
ввода/вывода, Райан Дал напоминает об относительном времени доступа к объектам.
Доступ к объектам в памяти (порядка наносекунд) производится быстрее, чем к
объектам на диске или посети (миллисекунды или секунды). Время доступа к
внешним объектам измеряется несметным количеством тактовых циклов и может
оказаться вечностью, если клиент, не дождавшись загрузки страницы в течение
двух секунд, устанет пялиться на окно браузера и отправится в другое место.
В Node вышеупомянутый запрос следовало бы
записать так:
query( SELECT * from db', function
(result) {
// произвести какие-то операции с результатом
}):
Разница в том, что теперь результат запроса не
возвращается в качестве значения функции, а передается функции обратного
вызова, которая будет вызвана позже. Таким образом, возврат в цикл обработки событий
происходит почти сразу, и сервер может перейти к обслуживанию других запросов.
Одним из таких запросов будет ответ на запрос, отправленный базе данных, и
тогда будет вызвана функция обратного вызова. Такая модель быстрого возврата в
цикл обработки событий повышает степень использования ресурсов серверов. Это
прекрасно для владельца сервера, но еще больший выигрыш получает пользователь,
перед которым быстрее открывается содержимое страницы.
В наши дни веб-страницы все чаще собирают данные
из десятков источников. Каждому нужно отправить запрос и дождаться ответа на
него. Асинхронные запросы позволяют выполнять эти операции параллельно -
отправить сразу все запросы, задав для каждого собственный обратный вызов, и,
не дожидаясь ответа, вернуться в цикл обработки событий. А когда придет ответ,
будет вызвана соответствующая ему функция. Благодаря распараллеливанию данные
можно собрать гораздо быстрее, чем, если бы запросы выполнялись синхронно, один
за другим. И пользователь по ту сторону браузера счастлив, так как страница
загружается быстрее.
.3 Производительность и использование процессора
Своей притягательностью платформа 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, которая позволяет реализовать
представительное подмножество технологии объектно-ориентированного
проектирования.
Список использованной литературы