Impress Application Server простыми словами

[CuamckuyKot]

Уважаемый автор, Вам не кажется, что одной страницы документации маловато будет? Каким бы гениальным не был продукт — трудно будет собрать аудиторию без подробной документации.

В Wiki на Github'е почти пусто…

[MarcusAurelius]

До текущего момента делать документацию было бессмысленно, структура и архитектура менялась очень динамично и документация бы мгновенно устаревала. Поэтому, в качестве бета-тестеров в течении последнего года выступали мои друзья и команда разработки, которые испытывали все неудобства быстро развивающегося продукта на себе, хотя были и совершенно незнакомые программисты, очень смелые, нужно думать, ребята. Каждые 5-10 минорных версий совместимость обрывалась и я старался сгладить эти проблемы, помогая в быстром изменении проектов и ведя подробные логи изменений, которые стали хорошей заменой документации на время активной разработки. Перед каждым обновлением версии нужно было заглянуть в лог изменений, где были подсказки по конвертации, иногда хватало сделать замену строки, а иногда блоки кода переносились в другое место. В любом случае, сейчас структура приложений уже почти закреплена и, в ближайшее время, к выходу версии 0.2, будет подробная документация.

[MarcusAurelius]

Пилотных внедрений уже много в таких областях: приложения баз данных, автоматизация производства, сетевая безопасность, медицина, телевидение, образование. Я и авторы этих внедрений, будем постепенно рассказывать о них, но документация — прежде этого.

[nomadmoon]

Надеюсь продолжение не задержится.
Пробовал экспериментировать с node.js но оттолкнуло то что начинать приходится, образно говоря, с «выплавки руды».

[asavin]

Почему вы не используете jsdoc?

[MarcusAurelius]

С удовольствием бы использовал и генерил бы доки из кода, но из-за особенностей структуры ядра IAS, jsdoc не всегда понимает к чему относятся методы, они часто попадают в область видимости через нетривиальные механизмы, через фабрику прототипов, через примеси и замыкания, а некоторые даже из контекста песочницы v8, и jsdoc запутывается. Кто-то уже пробовал прикрутить, но сталкивался с проблемами, может не полностью разобрался и это все же как-то можно устроить.

[asavin]

jsdoc — это же просто формат записи комментариев. Не обязательно использовать какой-то парсер/генератор документации, чтобы начать писать комментарии в общепринятом формате.

[MarcusAurelius]

Если мы научимся из него доки генерить, то да, а так он мне по синтаксису не очень нравится, возможно другой парсер или настройки/модификации какие помогут.

[hell0w0rd]

Если честно — никому не нужны доки по jsdoc и прочие *doc. Но они таки нужны для IDE. В правильных IDE дается правильный автокомплит, при наличии *doc.

[MarcusAurelius]

Так в том то и дело, что IDE используют jsdoc как парсер и он путается, не может адекватно распарсить и проанализировать исходники Impress с комментариями и не дает ни автокомплита, ни других подсказок.

[StreetStrider]

После прочтения возникло несколько вопросов:
1. Поддерживается ли возврат промиса из обработчика, вместо использования callback?
2. Как внутри обработчика осуществляется подгрузка стандартных имён (setTimeout) и имён ноды (request), а также их запрет?
3. Поддерживается ли .htm, как формат, наряду с .html?
4. Что подразумевается под шиной событий в части про WS? Означает ли она наличие механизмов, которые позволят сделать сокетное взаимодействие так, что можно выкинуть socket.io?

[MarcusAurelius]

1. Нет, только callback
2. У каждого приложения есть /config/sandbox.js, в нем параметр global, он по умолчанию закомментирован, это значит, что нужно пробрасывать в global приложения все стандартные имена. Но если его раскомментировать и удалить из списка require, например, то он не будет виден в приложении.
3. Да, все расширения, кроме прямо заданных (.json, .jsonp...) обрабатываются как html, т.е. .htm будет работать как .html
4. Точно, в приложении, что идет как пример, работают два варианта получения сообщений с сервера, через WebSockets и SSE, это без socket.io

[StreetStrider]

По поводу (1), я спрашиваю потому, что если поддержка промисов будет, то обработчики будут очень гладко интегрироваться с существующим кодом на промисах. Причём и в плане возврата данных и в плане обработки ошибок. Сейчас, естественно, можно привязать callback на then и на треть проблему решить, но нативная интеграция с промисами во много крат лучше. Также это двигает всю систему в сторону поддержки корутин (прям как в Koa).

Так или иначе, меня очень заинтересовал impress, и я рад, что всё это развивается.

По поводу (4) это очень круто, мне не нравятся существующие решения для сокетов. Вот socket.io, уже упомянутый, акцентирует внимание на событиях. С моей точки зрения это неверно, а надо акцентировать внимание на протоколах. Ведь мы используем события просто как не самую удачную модель над некоторым протоколом нашего приложения. Я считаю в сокетной либе кроме одиночных событий и broadcast-сообщений должны быть реквесты (также как это делается в HTTP, необходимость в реквестах никуда не исчезает).

Я даже задумываюсь над написанием либы, которая в качестве отправной точки постулирует два пункта: 1. либа инициализируется объектом-протоколом, 2. можно делать реквесты, которые мультиплексируются в сокете.

[MarcusAurelius]

По поводу промисов, я планирую их реализацию в 0.3 уже, потому, что это изменит многие вещи, а хотелось бы ответвить уже 0.2 и держать ее в стабильном виде для ежедневной разработки. Быстрое развитие — это конечно хорошо, но в 0.1 все страдали от того, что каждые 10-15 минорных версий обязательно что-то критическое менялось и нужно было рефакторить приложения, а отказаться от обновлений тоже нельзя, потому, что в них и ошибки же закрываются.

Одна из основных фич в том, что на одном порту можно сделать все, мультиплексируется по урлам, на одном урле SSE, на другом WebSocket, и тех же событийных каналов много можно одновременно на разных урлах держать, ну и на том же порту API и стриминг и статика и контент и все остальное. На ноде же обычно много портов открыто для каждой задачи специфический порт, и так выходит, что даже для не очень сложных приложений уже 2-5 портов открыто. А потом какой-то маршрутизатор рубит все кроме 80 или CORS не пропускает или еще что-то, в общем мультиплексирование в ноде не развито совсем.