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

[btd]

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

[btd]

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

[MarcusAurelius]

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

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

[inlanger]

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

[MarcusAurelius]

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

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

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

[btd]

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

[MarcusAurelius]

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

[MarcusAurelius]

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

[btd]

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

[meettya]

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

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

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

[MarcusAurelius]

Я знаком с мнением, о том, что глобальные объекты это плохо, но считаю, что плохи они только в глубоко прикладном коде (при моделировании предметной области, при очень специфического кода для конкретных задач), а вот при разработке абстрактного кода, это дает серьезные преимущества. Давайте не мыслить шаблонами, не будем делать из программирования догматическую веру, лучше рассмотрим аргументы и примеры. Сначала статья про этот подход к модульности: Паттерны 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]

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

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

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

[zag2art]

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

[MarcusAurelius]

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