MarcusAurelius Sep 23 2013 at 08:58

Impress: многоцелевой сервер приложений для Node.js

7 min

17K

Website development*JavaScript*Node.JS*

+29

Comments 15

btd Sep 23 2013 at 10:21

А зачем в коде добавлена «возможность» запуска этого добра в браузере?

btd Sep 23 2013 at 10:25

Вы бы еще подумали над разбивкой файлов на более меньшие части. У вас в github.com/tshemsedinov/impress/blob/master/lib/impress.js и работа с печеньками и работа с кластером, sse, и куча всего еще.

MarcusAurelius Sep 23 2013 at 14:19

1. Это только один файл global.js заточен под запуск на клиенте и на сервере. Почти все, что он содержит, действительно нужно и там и там.
2. Ядро не очень большое (44кб), и я вижу, как его еще оптимизировать, но SSE действительно лучше вынести. Тем более, что паттерн модулей в Impress, позволяет писать код с высокой связанностью даже в разных файлах, что значительно удобнее для ядра:

(function(impress) {
	impress.methodName = function(callback)
	}
} (global.impress = global.impress || {}));

inlanger Sep 23 2013 at 10:47

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

UFO landed and left these words here

MarcusAurelius Sep 23 2013 at 14:58

Решает, но это альтернативный подход и он позволяет писать быстрее и кода меньше, например, очень показательно в этом плане создание новых обработчиков URL для API или страниц. На Impress не нужно даже перестартовывать систему, просто создается папка, в ней делается файл get.js (или post.js, в зависимости от типа http запроса) и кода пару строк. Этот файл можно изменять и удалять без перезапуска системы, можно выложить половину приложения просто скопировав папки без перезапуска. Impress следит за файловой системой и все подтянет в память, при старый код завершит свою работу корректно, если он в момент изменения исполняется.

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

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

btd Sep 23 2013 at 15:31

Было бы очень интересно взглянуть на такое сравнение.

MarcusAurelius Sep 23 2013 at 15:48

Я думаю, что правильнее, если я закажу такое сравнение сторонним экспертам.

MarcusAurelius Sep 23 2013 at 14:43

Я думал использовать внешние шаблонизаторы, но разочаровался в их производительности и концептуальности. Например, если посмотреть в код EJS, то там куча синхронных операций, в том числе с файловой системой, что для неблокирующей ноды вообще смертельно. Я не знаю как его используют, разве что, вовсе не смотрят код подключаемых модулей. И встроенный в Impress шаблонизатор очень сильно структурно срощен с кешем в оперативной памяти, не знаю, можно ли будет какой-то внешний шаблонизатор так встроить. Мне насоветовали несколько, но ни один не приглянулся. А начав использовать Impress для своих же проектов, мы с коллегами обнаружили, что очень мало используем серверный шаблонизатор, в основном пишем API и передаем JSON на клиент, где уже рендерим в зависимости от платформы (браузер, мобильное приложение или даже встроенная система на контроллере, где та же нода работает). Использование же клиентских шаблонизаторов не регламентируется и очень просто реализуется.

btd Sep 23 2013 at 15:31

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

meettya Sep 23 2013 at 22:42

Есть такой вопрос провокационный — а почему Вы не пишите на node.js?

Зачем Вы изобрели собственный механизм импорта\экспорта?
Почему не используете сторонние клиентские библиотеки — для работы с датой, строками и т.д? Всякие lodash-underscore уже стандарт де-факто.

Я уж молчу про то, что использование global — жуткий моветон, который еще как-то можно простить в тестах, но в продакшен-коде — ни-ни.

MarcusAurelius Sep 23 2013 at 23:47

Я знаком с мнением, о том, что глобальные объекты это плохо, но считаю, что плохи они только в глубоко прикладном коде (при моделировании предметной области, при очень специфического кода для конкретных задач), а вот при разработке абстрактного кода, это дает серьезные преимущества. Давайте не мыслить шаблонами, не будем делать из программирования догматическую веру, лучше рассмотрим аргументы и примеры. Сначала статья про этот подход к модульности: Паттерны JavaScript модулей в Impress для node.js и браузеров. Понятно, что это не серебряная пуля и он имеет свою сферу эффективного применения и свои ограничения. А вот почему в Impress такой подход себя оправдывает:

Позволяет разбивать один модуль на несколько файлов, не теряя высокой связанности кода, его монолитности. Широко распространенный способ импорта/экспорта через require и exports не позволяет этого, он наоборот нужен для того, чтобы делать слабосвязанный код, это не хорошо и не плохо, просто это инструменты для разных целей.
Дает возможность делать многослойные абстракции, то есть, сначала определять общий для модуля код и структуры данных, а потом их выборочно расширять. Например, сначала загружается db.js, а потом один или несколько драйверов БД: db.mongodb.js, db.mysql.js, db.memcached.js, но все они встраиваются в структуры нижнего слоя, так, что основные методы драйверов этих БД совместимы и соединения они хранят в одном хеше. А потом опционально можно расширить интерфейс для MySQL, подгрузив db.mysql.introspection.js с методами интроспекции и db.mysql.schema.js с транслятором схем и т.д.
Ну и основная причина: этот метод значительно сокращает код при создании обработчиков для страниц и AJAX-обработчиков. Каждый обработчик хранится в отдельном файле и если из них всех начать делать кучу require, то это бы раздувало код. Например, в любом модуле можно сразу использовать глобальный объект async, который очень часто нужен, сразу пишем async.eachSeries(...)

meettya Sep 24 2013 at 00:23

Ну, многослойные абстракции нам дает DI, за связанностью следит ООП, а сокращать код помогают mixin-ы.

Я как бы не настаиваю, но есть некие best practice, игнорировать которые черевато боком, мне ли не знать.

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

zag2art Sep 24 2013 at 19:12

Вопрос: не возникают ли у вас проблемы с автодополнением в редакторе кода в связи с использованием глобальных переменных? Ну и если автодополнение работает — чем пользуетесь?

MarcusAurelius Sep 24 2013 at 19:39

Дело в том, что в этом вопросе я не могу подсказать ничего дельного, на меня ориентироваться нельзя, я экстремист, фанатик и фундаменталист, работаю исключительно без автодополнения в FAR. Но я спрашу наших ребят, как у них в саблайме и вебшторме.