Comments 30
И все-таки JavaScript для server-side приложений — слишком нишевая вещь.
>Так же ни один из фреймворков не имеет механизмов синхронизации данных между клиентом и сервером и оставляет реализацию этого на нашу совесть.
Не правда ваша. Как минимум Vaadin имеет.
Не правда ваша. Как минимум Vaadin имеет.
Vaadin выполняет совсем другую задачу, он расчитан больше на интранет. Паблик сайты на ваадине такая же редкость как мамонты в наше время.
Хорошо. Но дело в том как это реализовано.
В derby.js обмен данными идет через github.com/josephg/node-browserchannel
Это такая штука, которую например Google в Gmail использует, потому что никакие веб-сокеты не дают гарантии что сообщения прийдут в том порядке, в котором ушли.
Для синхронизации данных используется sharejs.org
Это подобно тому что например Google использовал в Google Waves.
А у Vaadin что? Ajax? Простите за вопрос.
В derby.js обмен данными идет через github.com/josephg/node-browserchannel
Это такая штука, которую например Google в Gmail использует, потому что никакие веб-сокеты не дают гарантии что сообщения прийдут в том порядке, в котором ушли.
Для синхронизации данных используется sharejs.org
Это подобно тому что например Google использовал в Google Waves.
А у Vaadin что? Ajax? Простите за вопрос.
У «подробного сравнения» есть хабраперевод habrahabr.ru/post/191664/
Вы видели что творит Vaadin? на каждый чих шлет ajax. ИМХО если мне приходится избавляться от чего-то в фреймворке, а не добавлять — это не тот инструмент.
Видел, это называется не «творит», а выполняет свою задачу.
Ибо Есть проекты в которых в этом нет необходимости, а есть такие, в которых это имеет смысл.
Вы вообще в курсе, что разные инструменты предназначены для разных задач?..
Ну и опять же, все кричат «он жрет много трафика, на каждый чих запрос и т.д.», а на деле это байты, и проект отлично работает с мобилки или планшета через GPRS.
P.S. По поводу вашего ИМХО. Все верно, если вы пытаетесь выпилить основной функционал из фреймворка, то значит вы что-то делаете не так) И скорее всего пытаетесь гвоздь закручивать, а не забивать)
P.S.2. Vaadin начиная с 7-й версии разделен на клиентскую и серверную части, так что можно вполне писать один клиент со своей логикой, который не будет «на каждый чих слать ajax».
Ибо Есть проекты в которых в этом нет необходимости, а есть такие, в которых это имеет смысл.
Вы вообще в курсе, что разные инструменты предназначены для разных задач?..
Ну и опять же, все кричат «он жрет много трафика, на каждый чих запрос и т.д.», а на деле это байты, и проект отлично работает с мобилки или планшета через GPRS.
P.S. По поводу вашего ИМХО. Все верно, если вы пытаетесь выпилить основной функционал из фреймворка, то значит вы что-то делаете не так) И скорее всего пытаетесь гвоздь закручивать, а не забивать)
P.S.2. Vaadin начиная с 7-й версии разделен на клиентскую и серверную части, так что можно вполне писать один клиент со своей логикой, который не будет «на каждый чих слать ajax».
А сравнение серверной нагрузки никто не предоставит? А то банально на главной такой скрипт будет — не ляжет ничего при больших нагрузках?
А что мешает использовать express + angular?
Ничто не мешает, просто express и angular — это уже два фреймфорка, тогда как derby — fullstack, работает и на стороне сервера и на стороне клиента. На самом деле derby сам по себе работает на express.
Ничего не мешает. Просто Derby — это несколько больше чем просто MVC на клиенте + REST.
Лично для меня это пройденный этап, вот тут писал об это: habrahabr.ru/post/191664/#comment_6666124
Лично для меня это пройденный этап, вот тут писал об это: habrahabr.ru/post/191664/#comment_6666124
Эта связка обеспечит бесшовную синхронизацию?
OfflineМожно ли создавать также приложения без участия сервера — скажем, для PhoneGap? Я просто такого у них не видел, всегда требуется backend, или что под «offline» подразумевалось?
Offline пока полностью не реализован. Но база заложена. Есть share.js, который может мержить данные с клиентов, обрабатывая конфликты с учетом времени изменения. То есть если клиент пропал на время и потом вернулся, его изменения лягут в базу как надо даже сейчас.
Есть планы сделать на каждом клиента базы данных (indexed DB), чтобы можно было не просто пропадать, но и браузер перезагрузить например ничего не потеряв. На самом деле ничего не мешает этого добавить сейчас.
По поводу PhoneGap — интересный вопрос. Если вы можете запустить node.js + mongodb + redis на телефоне, то наверное можно использовать.
Есть планы сделать на каждом клиента базы данных (indexed DB), чтобы можно было не просто пропадать, но и браузер перезагрузить например ничего не потеряв. На самом деле ничего не мешает этого добавить сейчас.
По поводу PhoneGap — интересный вопрос. Если вы можете запустить node.js + mongodb + redis на телефоне, то наверное можно использовать.
Я было подумал, что фреймворк умер; долгое время последний пост в их блоге был от 23 октября 2013; по сравнению с постоянной активностью команды meteor.js это выглядело не очень.
В основном активность происходит в Google Groups. После последнего поста в блоге было много мажорных обновлений. Просто у Дерби в отличие от Метеора нету людей занимающихся маркетингом фуллтайм. И коммунити Дерби значительно меньше. Это можно объяснить опять же маркетингом и высоким порогом входа.
Раньше я пробовал Метеор. Вот тут немного написал про впечатления: habrahabr.ru/post/191664/#comment_6666236
Раньше я пробовал Метеор. Вот тут немного написал про впечатления: habrahabr.ru/post/191664/#comment_6666236
Многообещающе выглядит, но, судя по этому, проект очень сырой. :( Там авторы онлайн-приложения приняли непростое решение полностью переписать его с Derby на Angular.
Да, Tyler со своим habitrpg был первым кто выложил что-то более менее серьезное в продакшен на дерби. Если мне не изменяет память это было осенью 2012. Ну и как всякий первооткрыватель, он столкнулся с некоторыми проблемами.
Те проблемы со стабильностью, которые были в версии 0.3, решены в версии 0.5. Сейчас дерби стабилен как никогда. Сам Tyler пишет об этом вот здесь: github.com/lefnire/habitrpg/issues/1247
Главная причина почему он не стал обновлятся до версии 0.5 была в том, что до определенного момента версия 0.5 требовала чтобы ваша база данных полностью сидела в редис, что для больших данных не возможно ввиду ограничения оперативной памяти. Это проблема решена несколько дней назад с появлением livedb 2.0, вот тут Joseph писал об этом: groups.google.com/forum/#!topic/derbyjs/7KPaTMTqceU
Сейчас редис — это что-то наподобие кэша для последних операций. И полагаю, так и должно быть.
Tyler давно был большим фанатом Angular, что не мешало ему в свое время сделать выбор в пользу Derby. Если интересно мое мнение по Angular, вот тут немного писал: habrahabr.ru/post/191664/#comment_6666124
Те проблемы со стабильностью, которые были в версии 0.3, решены в версии 0.5. Сейчас дерби стабилен как никогда. Сам Tyler пишет об этом вот здесь: github.com/lefnire/habitrpg/issues/1247
Главная причина почему он не стал обновлятся до версии 0.5 была в том, что до определенного момента версия 0.5 требовала чтобы ваша база данных полностью сидела в редис, что для больших данных не возможно ввиду ограничения оперативной памяти. Это проблема решена несколько дней назад с появлением livedb 2.0, вот тут Joseph писал об этом: groups.google.com/forum/#!topic/derbyjs/7KPaTMTqceU
Сейчас редис — это что-то наподобие кэша для последних операций. И полагаю, так и должно быть.
Tyler давно был большим фанатом Angular, что не мешало ему в свое время сделать выбор в пользу Derby. Если интересно мое мнение по Angular, вот тут немного писал: habrahabr.ru/post/191664/#comment_6666124
Можно ли в derby вообще без redis? Допустим только mongo? И с какими бд сейчас вообще работает?
redis обязателен.
Для того чтобы синхронизировать данные клиентов нужна некоторая модель событий (так называемая pub-sub). Это возможно реализовать в коде. Но минус будет в том что ваше приложение не сможет масштабироваться. Лучше когда это будет в базе данных. К сожалению в mongo этого нету. А в redis есть и это работает очень быстро. По этому без redis никак. В нем хранится история (сами задаете сколько) последних операций. По сути кэш.
Это всё проиходит вот тут: github.com/share/livedb
mongo не обязательно.
По поводу других бд: архитектура Derby позволяет использовать любые базы данных. Вот таким способом livedb соединен с mongo: github.com/share/livedb-mongo Вы можете написать свой адаптер для любой базы данных.
К тому же вы можете хранить данные в одной базе, а операции в другой или вообще операции не хранить (кроме кэша в редисе).
Чем вас пугает redis?
Для того чтобы синхронизировать данные клиентов нужна некоторая модель событий (так называемая pub-sub). Это возможно реализовать в коде. Но минус будет в том что ваше приложение не сможет масштабироваться. Лучше когда это будет в базе данных. К сожалению в mongo этого нету. А в redis есть и это работает очень быстро. По этому без redis никак. В нем хранится история (сами задаете сколько) последних операций. По сути кэш.
Это всё проиходит вот тут: github.com/share/livedb
mongo не обязательно.
По поводу других бд: архитектура Derby позволяет использовать любые базы данных. Вот таким способом livedb соединен с mongo: github.com/share/livedb-mongo Вы можете написать свой адаптер для любой базы данных.
К тому же вы можете хранить данные в одной базе, а операции в другой или вообще операции не хранить (кроме кэша в редисе).
Чем вас пугает redis?
Если можно, несколько вопросов:
- Есть ли в derby возможность спрятать код от клиента, чтобы он работал только на сервере?
- Очень интересуют детали работы синхронизации моделей через редис:
- Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
- На сколько шустро это работает?
- Можно эту синхронизацию отключать для определённых моделей?
- Если js, не дай бог, выключен, страница отобразится нормально?
Есть ли в derby возможность спрятать код от клиента, чтобы он работал только на сервере?
Конечно. Вам не что не мешает делать ajax-запросы и выполнять код на сервере, ведь derby.js — это обычное express.js приложение. Также обсуждался встроенный механизм для этого (server hooks), например тут. Но к сожалению так сходу не могу найти информацию об этом. Возможно он был в версии 0.3 и его пока не добавили в 0.5.
Очень интересуют детали работы синхронизации моделей через редис:
Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
Да правильно. Но на самом деле немного сложнее. Каждое приложение derby.js на сервере содержит объект store (тут происходит вся магия), из которого вы создаете модели (model). Модели могут быть на сервере, а могут быть на клиенте (связь через browserchanel). Если это первый запрос на сервер (тот при котором на клиент загружается приложение), то созданная на сервере модель будет сериализованна и отправлена на клиент. Вся работа с данными идет через модели (api одинаковый на сервере и клиенте). Вы можете просто читать какие-то данные из бд или записывать в нее. Так же вы можете подписаться (subscribe) на определенные данные (коллекцию, сущность, свойство сущности или даже произвольную выборку через queries), тогда store будет ловить все события из редис, связанные с подписанными данными этой модели и обновлять эти данные на этой модели. Разные модели могут быть подписаны на разные данные. Более того, derby приложение масштабируется, то есть вы можете запустить несколько derby приложений (на одном или разных серверах) каждое со своим store для одной и той же базы данных.
Для связи между сервером и клиентом используется browserchanel (как в Gmail), потому что веб-сокеты не гарантируют соблюдения порядка получения запросов.
На сколько шустро это работает?
Не могу привести каких-то тестов. Полагаю на столько же шустро, на сколько шустро работает pub-sub в redis.
Можно эту синхронизацию отключать для определённых моделей?
Вы сами выбираете что вам синхронизировать.
Если js, не дай бог, выключен, страница отобразится нормально?
Да. Страница отрендерится на сервере.
Конечно. Вам не что не мешает делать ajax-запросы и выполнять код на сервере, ведь derby.js — это обычное express.js приложение. Также обсуждался встроенный механизм для этого (server hooks), например тут. Но к сожалению так сходу не могу найти информацию об этом. Возможно он был в версии 0.3 и его пока не добавили в 0.5.
Очень интересуют детали работы синхронизации моделей через редис:
Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
Да правильно. Но на самом деле немного сложнее. Каждое приложение derby.js на сервере содержит объект store (тут происходит вся магия), из которого вы создаете модели (model). Модели могут быть на сервере, а могут быть на клиенте (связь через browserchanel). Если это первый запрос на сервер (тот при котором на клиент загружается приложение), то созданная на сервере модель будет сериализованна и отправлена на клиент. Вся работа с данными идет через модели (api одинаковый на сервере и клиенте). Вы можете просто читать какие-то данные из бд или записывать в нее. Так же вы можете подписаться (subscribe) на определенные данные (коллекцию, сущность, свойство сущности или даже произвольную выборку через queries), тогда store будет ловить все события из редис, связанные с подписанными данными этой модели и обновлять эти данные на этой модели. Разные модели могут быть подписаны на разные данные. Более того, derby приложение масштабируется, то есть вы можете запустить несколько derby приложений (на одном или разных серверах) каждое со своим store для одной и той же базы данных.
Для связи между сервером и клиентом используется browserchanel (как в Gmail), потому что веб-сокеты не гарантируют соблюдения порядка получения запросов.
На сколько шустро это работает?
Не могу привести каких-то тестов. Полагаю на столько же шустро, на сколько шустро работает pub-sub в redis.
Можно эту синхронизацию отключать для определённых моделей?
Вы сами выбираете что вам синхронизировать.
Если js, не дай бог, выключен, страница отобразится нормально?
Да. Страница отрендерится на сервере.
Спасибо!
А как происходит ограничение доступа к данным? Есть какой-то аналог этого?
А как происходит ограничение доступа к данным? Есть какой-то аналог этого?
Sign up to leave a comment.
Derby.js — новый взгляд на веб-разработку