Derby.js — новый взгляд на веб-разработку



Вы веб-разработчик?

Для вас есть новости.

В чем собственно проблема?


Все веб-фреймворки можно разделить на группы. У каждой из этих групп есть свои достоинства и недостатки.

Сервер-ориентированные

Например: RoR, Django, Asp Net, Express.js
Генерируют html на сервере.
Такой подход хорош для статических страничек.
Но как только вы хотите сделать что-то интерактивное, то начинаете утопать в jQuery-коде.

Клиент-ориентированные

Например: Backbone.js, Knockout.js, Ember.js, Batman.js
Генерируют html прямо на клиенте из темплейтов. Код на клиенте структурирован.
Хорошо для интерактивных сайтов.
Не отменяет необходимость использовать сервер-ориентированный фреймворк, что ведет к дублированию кода (модели, валидация и т.д.)

Кросс-компилируемые

Например: GWT, Cappuccino
Позволяют писать всё на одном языке.
Очень большой уровень абстракции.
Шаг вправо, шаг влево — расстрел.

Так же ни один из фреймворков не имеет механизмов синхронизации данных между клиентом и сервером и оставляет реализацию этого на нашу совесть.

Давайте помечтаем


Что мы хотим от веб-фреймворка?

  • Один язык (Javascript) для повторного использования кода на сервере и клиенте
  • Генерация html первый раз на сервере (для быстрой загрузки), следующие разы на клиенте (для интерактивности)
  • MVC для структуры кода
  • Реактивная привязка вида и модели (изменения модели немедленно отражаются в html и наоборот)
  • Встроенная синхронизация данных между сервером и всеми клиентами
  • Offline


Такое бывает?


Да, Derby.js

github
twitter
Вопросы лучше всего задавать в Google Groups
Пример приложения: habitrpg

Создатели Derby.js: Nate и Brian

P.S.:
Основной конкурент — Meteor.
Из плюсов — ниже порог входа. Из минусов — не поддерживает npm и нет генерации html на сервере.
Подробное сравнение здесь.

[ Материалы по Derby.js ]
Share post

Comments 30

    0
    И все-таки JavaScript для server-side приложений — слишком нишевая вещь.
      +3
      Года три назад я бы поверил вашим словам :)
        0
        И все-таки не JavaScript для server-side приложений — слишком нишевая вещь.
        +2
        >Так же ни один из фреймворков не имеет механизмов синхронизации данных между клиентом и сервером и оставляет реализацию этого на нашу совесть.

        Не правда ваша. Как минимум Vaadin имеет.
          0
          Vaadin выполняет совсем другую задачу, он расчитан больше на интранет. Паблик сайты на ваадине такая же редкость как мамонты в наше время.
            +2
            Хорошо. Но дело в том как это реализовано.
            В derby.js обмен данными идет через github.com/josephg/node-browserchannel
            Это такая штука, которую например Google в Gmail использует, потому что никакие веб-сокеты не дают гарантии что сообщения прийдут в том порядке, в котором ушли.
            Для синхронизации данных используется sharejs.org
            Это подобно тому что например Google использовал в Google Waves.

            А у Vaadin что? Ajax? Простите за вопрос.
              0
              Допиленный GWT, ЕМНИП
            +3
            У «подробного сравнения» есть хабраперевод habrahabr.ru/post/191664/
              0
              Вы видели что творит Vaadin? на каждый чих шлет ajax. ИМХО если мне приходится избавляться от чего-то в фреймворке, а не добавлять — это не тот инструмент.
                +1
                Видел, это называется не «творит», а выполняет свою задачу.
                Ибо Есть проекты в которых в этом нет необходимости, а есть такие, в которых это имеет смысл.
                Вы вообще в курсе, что разные инструменты предназначены для разных задач?..
                Ну и опять же, все кричат «он жрет много трафика, на каждый чих запрос и т.д.», а на деле это байты, и проект отлично работает с мобилки или планшета через GPRS.

                P.S. По поводу вашего ИМХО. Все верно, если вы пытаетесь выпилить основной функционал из фреймворка, то значит вы что-то делаете не так) И скорее всего пытаетесь гвоздь закручивать, а не забивать)

                P.S.2. Vaadin начиная с 7-й версии разделен на клиентскую и серверную части, так что можно вполне писать один клиент со своей логикой, который не будет «на каждый чих слать ajax».
                  0
                  Он точно шлет ajax запрос? Http запрос сам по себе без тела содержит около 700 байт, по подсчетам в презентациях о http 2.0. Для таких задач придуманы веб-сокеты, может они используются?
                +1
                А сравнение серверной нагрузки никто не предоставит? А то банально на главной такой скрипт будет — не ляжет ничего при больших нагрузках?
                  +1
                  Всё зависит от вашего кода.

                  Вот проект от создателей derby в продакшене: lever.co
                  +1
                  А что мешает использовать express + angular?
                    +1
                    Ничто не мешает, просто express и angular — это уже два фреймфорка, тогда как derby — fullstack, работает и на стороне сервера и на стороне клиента. На самом деле derby сам по себе работает на express.
                      +1
                      Ничего не мешает. Просто Derby — это несколько больше чем просто MVC на клиенте + REST.
                      Лично для меня это пройденный этап, вот тут писал об это: habrahabr.ru/post/191664/#comment_6666124
                        0
                        Эта связка обеспечит бесшовную синхронизацию?
                        0
                        Offline
                        Можно ли создавать также приложения без участия сервера — скажем, для PhoneGap? Я просто такого у них не видел, всегда требуется backend, или что под «offline» подразумевалось?
                          +2
                          Offline пока полностью не реализован. Но база заложена. Есть share.js, который может мержить данные с клиентов, обрабатывая конфликты с учетом времени изменения. То есть если клиент пропал на время и потом вернулся, его изменения лягут в базу как надо даже сейчас.

                          Есть планы сделать на каждом клиента базы данных (indexed DB), чтобы можно было не просто пропадать, но и браузер перезагрузить например ничего не потеряв. На самом деле ничего не мешает этого добавить сейчас.

                          По поводу PhoneGap — интересный вопрос. Если вы можете запустить node.js + mongodb + redis на телефоне, то наверное можно использовать.
                          0
                          Я было подумал, что фреймворк умер; долгое время последний пост в их блоге был от 23 октября 2013; по сравнению с постоянной активностью команды meteor.js это выглядело не очень.
                            +2
                            В основном активность происходит в Google Groups. После последнего поста в блоге было много мажорных обновлений. Просто у Дерби в отличие от Метеора нету людей занимающихся маркетингом фуллтайм. И коммунити Дерби значительно меньше. Это можно объяснить опять же маркетингом и высоким порогом входа.

                            Раньше я пробовал Метеор. Вот тут немного написал про впечатления: habrahabr.ru/post/191664/#comment_6666236
                            +1
                            Многообещающе выглядит, но, судя по этому, проект очень сырой. :( Там авторы онлайн-приложения приняли непростое решение полностью переписать его с Derby на Angular.
                              +2
                              Да, 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
                                Можно ли в derby вообще без redis? Допустим только mongo? И с какими бд сейчас вообще работает?
                                  +1
                                  redis обязателен.
                                  Для того чтобы синхронизировать данные клиентов нужна некоторая модель событий (так называемая pub-sub). Это возможно реализовать в коде. Но минус будет в том что ваше приложение не сможет масштабироваться. Лучше когда это будет в базе данных. К сожалению в mongo этого нету. А в redis есть и это работает очень быстро. По этому без redis никак. В нем хранится история (сами задаете сколько) последних операций. По сути кэш.
                                  Это всё проиходит вот тут: github.com/share/livedb

                                  mongo не обязательно.
                                  По поводу других бд: архитектура Derby позволяет использовать любые базы данных. Вот таким способом livedb соединен с mongo: github.com/share/livedb-mongo Вы можете написать свой адаптер для любой базы данных.
                                  К тому же вы можете хранить данные в одной базе, а операции в другой или вообще операции не хранить (кроме кэша в редисе).

                                  Чем вас пугает redis?
                                    0
                                    Ничего. Интересна архитектура.
                              0
                              Если можно, несколько вопросов:

                              • Есть ли в derby возможность спрятать код от клиента, чтобы он работал только на сервере?
                              • Очень интересуют детали работы синхронизации моделей через редис:
                                • Я правильно понимаю, что при обновлении модели на клиенте это событие через веб-сокет попадает в редис и дальше раздаётся всем активным клиентам?
                                • На сколько шустро это работает?
                                • Можно эту синхронизацию отключать для определённых моделей?
                              • Если js, не дай бог, выключен, страница отобразится нормально?
                                0
                                Есть ли в 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, не дай бог, выключен, страница отобразится нормально?
                                Да. Страница отрендерится на сервере.

                            Only users with full accounts can post comments. Log in, please.