Хотя нет, все-таки осталась возможность написать что-нибудь тяжелое синхронное. Или просто сделать ошибку в цикле и устроить вечный луп. Или бросить эксепшен в setTimeout(). И прощай процесс.
Но тут уж и эрланг не спасет в большинстве случаев)
Не, я имею ввиду в обычном процессе. Он же один на процессор и может обслуживать дофига коннектов. Хотя я сейчас вот попробовал его уронить из своего кода и мне это не удалось. Так что проблема, видимо, стала не столь актуальной как на заре становления node, когда любая проблема валила весь сервер. А если они еще и научились передавать незавершенные коннекты другому процессу — вообще хорошо.
В общем да, проблема, похоже, стала не актуальной и можно ее вычеркивать. Спасибо.
Да, тут можно спорить, но, по-моему, клевее принять, что то, что продукты идут разными путями — хорошо. Для тех, кому хочется гибкости npm из коробки и стандартного для платформы стиля, есть derby. Для тех, кому хочется меньше boilerplate пусть и с меньшей гибкостью и большими отступлениями, есть meteor.
NPM-то они не сделали не просто так. Большинство из них ведь не в fibers-стиле, нада их под него адаптировать. Ну и другие причины есть. Где-то у них был большой топик про это.
Проблема в том, что если приложение зайдет на сбойную ветку во всем кластере, то это не поможет. Вероятность этого, конечно, гораздо меньше, но бывает всякое.
Плюс, одна нода может держать десятки тысяч коннектов. Все-таки неправильно, когда из-за сбоя у одного юзера, отвалятся все.
То что проблему пытаются закрыть — хорошо, но пока она существует и стоит учитывать ее при выборе технологии.
Преимущество в 30% может быть существенным на некоторых задачах. И может перекрыть преимущества node.
В общем, в очередной раз возвращаемся к тому, что все по задаче. Но и цифры знать неплохо. Может и созрею провести и выложить тесты.
Но все было бы просто, если бы у ноды были одни плюсы, но ведь есть и минусы.
Я вот подумываю сравнить ее с Erlang. На то есть две причины:
1) Нестабильность ноды. Я не одобряю эту веру Node-программистов в то, что они смогут писать приложения, которые никогда не падают ни на одной ветке. Эрланг же в этом плане весьма хорош. Упало и упало, все остальное продолжает работать.
2) Долгое время был уверен, что нода будет быстрее эрланга, но наткнулся на несколько тестов, которые говорят об обратном. Теперь хочется проверить это самому и увидеть, насколько же большая разница. Стоит ли овчинка выделки.
Но других потенциальных конкурентов ноде я сейчас не вижу.
Кстати, насчет монолитности Meteor. Они работают над тем, чтобы сделать его менее связным. Сейчас, например, можно удалить пакет standard-app-packages и набрать ядро из компонентов, которые тебе нужны. Заменив некоторые на свои.
Или можно отказаться от их сервера и реализовать DDP на чем угодно.
Так что при желании — все можно переделать. Может не так просто, как в конструкторе-derby, зато и целостность-удобство-простота в базовых сценариях у метеора, имхо, выше.
Не знаю как дерби, но и метеор, и ангуляр по заявлениям делают flush когда event loop'у больше нечем заняться, поэтому попадались рекомендации не использовать их в приложениях с активным юзерским вводом или расчетами, так как могут быть лаги с перерисовкой. Но на практике я не проверял, может и ок будет.
Кстати, полезность одного языка на сервере и клиенте скорее в унификации и отсутствии необходимости переключать сознание, чем в написании повторяемого кода. Повторяемого кода реально получается немного.
Например, та же валидация в случае полноценной модели на 90% сводится к десятку стандартных валидаторов. Большая часть из них однострочные или около того. Какие-то более сложные валидации получаются все равно разными для клиента и сервера, так что это не критично.
Возможно, это было бы критично для игр, где нужно оперативно считать все на клиенте, а потом перепроверять на сервере. Но в типичных CRUD-приложениях это не очень востребовано. Но в то же время эти фреймвоки не рекомендуются для игр, ибо перерисовывают состояние во время простоев, т.е. будут лаговать.
Насчет генерации на сервере — может и не придется. Это все же костыль, обусловленный кривизной поисковиков и медлительностью браузеров. И то, и другое все время улучшается и уже сейчас проблема не так уж актуальна для многих видов сайтов/сервисов.
Что касается синхронизации апдейтов через pub/sub — имхо, это просто. Да и они обещают допилить еще до первой версии.
Понятно, что если проект новый, то лучше начинать с JS и на клиенте, и на сервере. Но не всегда это возможно.
Fibers ничего не убивает. Он не синхронный, он псевдосинхронный. Зато его использование делает код в два раза короче и два раза понятнее. Очень правильно, что Meteor'овцы его использовали. Впрочем, это мое имхо. Хотите страдать — страдайте)
Изменения данных на одной ноде метеор рассылает сразу, а не после пулинга монго. Пулинг сделан для распространения между нодами. Но это, конечно, временный костыль. В планах у них использовать pub/sub для распространения событий между нодами, как в derby.
В Derby пока нравится Operational transformation. Компоненты и генерацию на сервере не смотрел. Спасибо за наводку, посмотрю.
Почти год использую Meteor и немного использовал Angular. Derby смотрел только мельком, ничего конкретного сказать про него не могу. Так что о Meteor vs Angular.
Для меня самые значимые плюсы Angular:
— Мощная система директив, позволяющая делать компоненты и добиваться высокого уровня повторного использования. В Meteor из коробки вы получаете просто handlebars, делать компоненты на котором — то еще извращение.
— Можно встроить куда угодно и на любом этапе. С любым бэкэдом.
— Более доделанный, не меняется все от версии к версии. Можно с минимальными опасениями использовать на продакшене.
— Более развитое комьюнити.
Но тем не менее, для себя я использую и допиливаю Meteor, потому что:
— Meteor это своего рода продолжение MVVM и на сервер. Я не хочу два раза заниматься одной и той же работой (на клиенте и сервере). Если я где-то обновляю значение, оно должно сразу обновляться везде. К тому же, Meteor без каких либо дополнительных усилий моментально раскидывает апдейты по всем клиентам, что логично для современного приложения.
— Meteor из коробки заточен на использование Node Fibers, что позволяет писать асинхронный код в линейном стиле на манер Erlang, а не заниматься извращением с асинхронной лапшой или каким-нибудь async. На клиенте это, понятно, невозможно, но за счет MVVM лапши тоже почти не возникает.
— Человечность и ощущение, что ребята стремятся скинуть всю работу, которую могут делать компьютеры, на компьютеры, а не на программиста. На хабре проскакивало мнение, что Meteor это чуть ли не фреймвок для домохозяек. Отнюдь. Механика его работы очень сложна, много магии. Да, легко сделать hello world, но без понимания внутренней кухни не написать ничего серьезного. Зачем тогда так заморачиваться? Чтобы по максимуму писать и поддерживать только полезный код, а не boilerplate.
Основные недостатоки Meteor зеркалят преимущества Angular: сырой; handlebars а не компоненты/директивы; нет модели (валидация руками, нет виртуальных свойств); не подходит для олдскульных постраничных сайтов; завязан на свой бэкэнд; небольшое комьюнити (но быстро растет).
Вообще-то ими пользуются в основном для создания колорита драм-машины. Как замену живым барабанам всерьез их никто не воспринимает.
Из топовых драм-модулей еще можно что-то выжать, но быстрее и круче настучать живьем. Только хороший барабанный сетап + микрофоны встанет под 30k $, а еще нужно помещение. Поэтому инди-исполнители вынуждены юзать драм-модули или писаться с колоритом дерьмового барабанного звука.
Интересно, конечно, но запись условий строками — ад.
Плюс уже есть JSR 303 (Bean Validation), который во многом делает тоже самое (и без строк). Современная реализация Java-контрактов должна быть с ним как-то интегрирована.
Но тут уж и эрланг не спасет в большинстве случаев)
В общем да, проблема, похоже, стала не актуальной и можно ее вычеркивать. Спасибо.
Надеюсь, скоро еще и что-то среднее появится.
Плюс, одна нода может держать десятки тысяч коннектов. Все-таки неправильно, когда из-за сбоя у одного юзера, отвалятся все.
То что проблему пытаются закрыть — хорошо, но пока она существует и стоит учитывать ее при выборе технологии.
Преимущество в 30% может быть существенным на некоторых задачах. И может перекрыть преимущества node.
В общем, в очередной раз возвращаемся к тому, что все по задаче. Но и цифры знать неплохо. Может и созрею провести и выложить тесты.
Но все было бы просто, если бы у ноды были одни плюсы, но ведь есть и минусы.
Я вот подумываю сравнить ее с Erlang. На то есть две причины:
1) Нестабильность ноды. Я не одобряю эту веру Node-программистов в то, что они смогут писать приложения, которые никогда не падают ни на одной ветке. Эрланг же в этом плане весьма хорош. Упало и упало, все остальное продолжает работать.
2) Долгое время был уверен, что нода будет быстрее эрланга, но наткнулся на несколько тестов, которые говорят об обратном. Теперь хочется проверить это самому и увидеть, насколько же большая разница. Стоит ли овчинка выделки.
Но других потенциальных конкурентов ноде я сейчас не вижу.
Или можно отказаться от их сервера и реализовать DDP на чем угодно.
Так что при желании — все можно переделать. Может не так просто, как в конструкторе-derby, зато и целостность-удобство-простота в базовых сценариях у метеора, имхо, выше.
Например, та же валидация в случае полноценной модели на 90% сводится к десятку стандартных валидаторов. Большая часть из них однострочные или около того. Какие-то более сложные валидации получаются все равно разными для клиента и сервера, так что это не критично.
Возможно, это было бы критично для игр, где нужно оперативно считать все на клиенте, а потом перепроверять на сервере. Но в типичных CRUD-приложениях это не очень востребовано. Но в то же время эти фреймвоки не рекомендуются для игр, ибо перерисовывают состояние во время простоев, т.е. будут лаговать.
Что касается синхронизации апдейтов через pub/sub — имхо, это просто. Да и они обещают допилить еще до первой версии.
Fibers ничего не убивает. Он не синхронный, он псевдосинхронный. Зато его использование делает код в два раза короче и два раза понятнее. Очень правильно, что Meteor'овцы его использовали. Впрочем, это мое имхо. Хотите страдать — страдайте)
Изменения данных на одной ноде метеор рассылает сразу, а не после пулинга монго. Пулинг сделан для распространения между нодами. Но это, конечно, временный костыль. В планах у них использовать pub/sub для распространения событий между нодами, как в derby.
В Derby пока нравится Operational transformation. Компоненты и генерацию на сервере не смотрел. Спасибо за наводку, посмотрю.
Для меня самые значимые плюсы Angular:
— Мощная система директив, позволяющая делать компоненты и добиваться высокого уровня повторного использования. В Meteor из коробки вы получаете просто handlebars, делать компоненты на котором — то еще извращение.
— Можно встроить куда угодно и на любом этапе. С любым бэкэдом.
— Более доделанный, не меняется все от версии к версии. Можно с минимальными опасениями использовать на продакшене.
— Более развитое комьюнити.
Но тем не менее, для себя я использую и допиливаю Meteor, потому что:
— Meteor это своего рода продолжение MVVM и на сервер. Я не хочу два раза заниматься одной и той же работой (на клиенте и сервере). Если я где-то обновляю значение, оно должно сразу обновляться везде. К тому же, Meteor без каких либо дополнительных усилий моментально раскидывает апдейты по всем клиентам, что логично для современного приложения.
— Meteor из коробки заточен на использование Node Fibers, что позволяет писать асинхронный код в линейном стиле на манер Erlang, а не заниматься извращением с асинхронной лапшой или каким-нибудь async. На клиенте это, понятно, невозможно, но за счет MVVM лапши тоже почти не возникает.
— Человечность и ощущение, что ребята стремятся скинуть всю работу, которую могут делать компьютеры, на компьютеры, а не на программиста. На хабре проскакивало мнение, что Meteor это чуть ли не фреймвок для домохозяек. Отнюдь. Механика его работы очень сложна, много магии. Да, легко сделать hello world, но без понимания внутренней кухни не написать ничего серьезного. Зачем тогда так заморачиваться? Чтобы по максимуму писать и поддерживать только полезный код, а не boilerplate.
Основные недостатоки Meteor зеркалят преимущества Angular: сырой; handlebars а не компоненты/директивы; нет модели (валидация руками, нет виртуальных свойств); не подходит для олдскульных постраничных сайтов; завязан на свой бэкэнд; небольшое комьюнити (но быстро растет).
Из топовых драм-модулей еще можно что-то выжать, но быстрее и круче настучать живьем. Только хороший барабанный сетап + микрофоны встанет под 30k $, а еще нужно помещение. Поэтому инди-исполнители вынуждены юзать драм-модули или писаться с колоритом дерьмового барабанного звука.
Почувствовать себя жалким человечишкой :P
Плюс уже есть JSR 303 (Bean Validation), который во многом делает тоже самое (и без строк). Современная реализация Java-контрактов должна быть с ним как-то интегрирована.