![](http://habrastorage.org/storage2/9f1/002/317/9f1002317a5dff57a94017a03927de0e.jpg)
Возможности и особенности
- Маршрутизация URL на базе файловой системы — создал каталог — вот уже и часть URL, каталог незамедлительно наследует все обработчики от родительского каталога, а все, что будет помещено в сам каталог, переопределит логику исполнения или внешний вид страниц. Т.к. в основном мы ориентируемся на одностраничные приложения с динамическим взаимодействием с сервером, то все это, по большей части, нужно не для генерации страниц, а для быстрого написания серверного API на базе JSON.
- Кеширование серверного JavaScript и шаблонов в оперативной памяти — все обработчики и шаблоны при первом обращении забираются в память, где снабжаются индексами для быстрого поиска при повторном использовании.
- Возможность изменения кода приложений без перезагрузки основного приложения — за всеми каталогами, из которых считывались файлы, устанавливается слежение, и при изменении кода и шаблонов на диске, мы обновляем кеш, а при удалении файлов — очищаем кеш.
- Обслуживание сразу множества портов, сетевых интерфейсов, хостов и протоколов — т.к. у нас statefull приложения, т.е. мы храним состояние в оперативной памяти (сессии пользователей и состояние других объектов предметной области), то очень полезно, чтобы все серверные компоненты, обслуживающие одного пользователя на разных портах (например HTTP и SSE), имели общую разделяемую память.
- Несколько стратегий запуска:
- Один процесс (все обслуживается в одном потоке обработки).
- Специализированные процессы (для каждого порта свой worker + главный процесс master).
- Многопоточная не специализированная обработка (однотипные workerы, не специализированные процессы, master принимает запросы со всех портов и распределяет их рандомно по workerам).
- Многопоточная обработка с привязкой клиентов по IP адресам к определенным workerам (sticky by IP) для того, чтобы последующие запросы клиента потом попадали именно в тот worker, в котором уже развернута его сессия и другие структуры состояния, с ним связанные.
- Специализация процессов с изоляцией по приложениям (не включена в релиз, тестируется) — если запущено несколько приложений в одной системе, и одно может мешать другому, то лучше разделить их в разные workerы.
- Отпочковывание отдельных процессов для обработки определенных URL (не включена в релиз, разрабатывается) — это специально для обработчиков, которые предполагают долгую блокирующую логику, для этих случаев, схема с общим реактором не подходит, а мы отдаем пользователю «запрос обрабатывается», отпочковываем обработчик, а в конце обработки он вернет результаты по IPC в родительский worker, который уже, например, по SSE вернет их клиенту.
- Встроенный простой шаблонизатор с поддержкой include, наследованием и переопределением фрагментов шаблонов в подкаталогах. Шаблонизатор имеет доступ только к данным, сформированным обработчиками бизнес-логики и помещенными в res.context. Если Вы спросите, почему я не прикрутил сюда готовый, например, EJS, то посмотрите их код, в EJS, например, куча синхронных операций, у других — другие дефекты, а ничего сложного то нам и не нужно для AJAX-приложений. На клиенте берите любой шаблонизатор — не регламентируется.
- Поддержка cookies и механизм сессий — в том числе состояния в памяти или хранимого состояния в MongoDB, если worker падает, то при следующем запросе состояние подымется из базы, а сохраняется оно только при внесении изменений. Неопознанные ключи сессий отвергаются и удаляются.
- Отдача статического контента и стриминг — тут еще много нужно дорабатывать, скоро появится кеширование статики в памяти и управление этим кешем в конфиге.
- Встроенный маршрутизатор запросов (reverse-proxy) с поддержкой url-rewriting — можем отдельные URLы, по регулярному выражению, перенаправлять на другой хост и порт, обеспечивая возврат ответа пользователю от него.
- Гибкая конфигурация в формате JSON с возможностью изменять без полной перезагрузки основного приложения (которая сейчас все еще иногда рушится).
- Простое логирование запросов — его или нужно развить или прикрутить готовое решение.
- Встроенные средства доступа к БД — в качестве БД пока только Mongo, но самостоятельно доступаться к другим базам не возбраняется.
Планы на ближайшее время
- Добавить поддержку оффлайн приложений (HTML5 Offline Applications Cache) с манифестами и т.д.
- Реализовать загрузку файлов через POST запросы.
- Кешировать статику в оперативной памяти с гибким управлением этим кешем из конфигурации.
- Прикрутить опциональный geoIP лукап.
- Сделать настраиваемые шаблоны страниц ошибок (404 и т.д.).
- Ввести ограничения доступа к каталогам через файлики access.js, в них помещаемые.
- Поддержка опционального вывода результатов API обработчиков не только в JSON, но и в XML (при моей индивидуальной непереносимости XML, прошу учесть сей героический шаг), а также, прием запросов в API в формате XML (держите меня семеро).
- Простенькая CMS с хранением контента в MongoDB.
- Плагин для отправки email из приложений.
- Поддержка SSE (Server-Sent Events) для трансляции событий с сервера на клиенты по инициативе сервера (сейчас в разработке).
- Демонизация и «graceful shutdown» (сейчас в разработке).
Установка и настройка
1. Ставим из npm (https://npmjs.org/package/impress)
$ npm install impress
2. Копируем шаблон проекта — содержимое каталога /node_modules/impress/examples/copyContentToProjectFolder переносим в каталог проекта (server.js, setup.js, config.js и каталог sites).
3. Насраиваем файл config.js пройдемся по разделам конфига:
databases — базы, которые будут автоматически открыты при старте и перечисленные коллекции будут доступны помещены таким образом: db.dbName.collectionName.find(…). Пример конфигурации:
dbName: { url: "mongodb://localhost:27017/dbName", collections: ["collname1", "collname2"] }
session — имя длина и набор символов для генерации сессионного cookie, имя базы для постоянного хранения сессий.
cluster — настройка стратегии инстанциирования (тип многопоточнисти).
servers — именованные сервера (интерфейс/порт), для каждого поле hosts — массив именованных хостов, которые нужно отдавать с этого сервера, static — массив масок файлов для отдачи статики, например ["/css/*", "/images/*", "/js/*", "/favicon.ico", "/index.html"].
hosts — именованные хосты (виртуальные хосты), можно использовать маски для именования, например "*.myhost.com".
routes — именованные маршруты переадресации запросов.
4. Для инициализации структур данных в MongoDB, запустите node setup.js и жмем «y».
5. В файле server.js можем написать еще дополнительный свой код на инициализацию:
require('impress'); impress.init(function() { // Сюда свой код });
6. И стартуем сервер
$ node server.js
Смотрим примеры
1. Шаблоны: при запущенном сервере открываем http://localhost
и шаблон смотрим тут: /sites/localhost/html.template
2. Пример переопределения шаблона «left.template» с наследованием логики, открываем http://localhost/override
и шаблон смотрим тут: /sites/localhost/override/left.template
базовый шаблон тут: /sites/localhost/html.template
обработчик серверной логики тут: /sites/localhost/request.js
3. Пример API метода с JSON ответом смотрим: http://localhost/api/examples/methodName.json
и код тут /sites/localhost/api/examples/methodName.json/get.js
4. Пример запуска анонимной сессии: http://localhost/api/auth/anonymousSession.json
и код соответственно: /sites/localhost/api/auth/anonymousSession.json/get.js
5. Пример POST запроса: усилием мысли делаем POST на localhost/api/auth/regvalidation.json с параметром «Email»
и код: /sites/localhost/api/auth/regvalidation.json/post.js
6. Пример доступа в базу MongoDB:: http://localhost/api/examples/getUsers.json
и код тут: /sites/localhost/api/examples/getUsers.json/get.js
Ссылки
На Github: https://github.com/tshemsedinov/impress
В npm: https://npmjs.org/package/impress
ссылка на оригинал статьи http://habrahabr.ru/post/182714/
Добавить комментарий