Изучаем Derby 0.6, пример #1

  • Tutorial
image
Последние несколько месяцев я участвую в нескольких проектах, разрабатываемых на Derby (реактивный fullstack javascript-фреймворк). Часть из них вполне успешно работает в продакшине, часть стартует в ближайшее время.

Пока я изучал данную технологию возникло несколько мыслей. Во-первых, информации о данной технологии крайне мало: документация скудна, а статьи, которые написаны (я про англоязычные), обычно пишутся людьми, потратившими от силы день-два на ее изучение. Во-вторых, есть небольшая группа людей, которые отлично знают данную технологию и используют ее в своих проектах, успешно решив все проблемы, о которые спотыкаются начинающие.

Идея у меня проста — поделиться полученными знаниями, если это конечно будет интересно и востребовано. Я хочу взять несколько примеров из проекта derby-examples и разобрать их по полочкам. Либо, воссоздавая их с нуля, попутно объяснить логику создания, с точки зрения специалиста, либо же, по готовому примеру объяснить те моменты, которые были не раскрыты в предыдущих примерах. Короче, если понравится, думаю разобрать 5-6 примеров.


Версия 0.6


Изучать будем derby версии 0.6. На данный момент выпущена версия 0.6 alpha 5. Она достаточно стабильна для того, чтобы мы начали переводить все свои проекты с 0.5 на нее. Новые же проекты все создаются исключительно на 0.6. Вот, например, type4fame — хобби-проект моего друга, сделан на 0.6.

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

Ради справедливости, здесь стоит добавить, что это все-таки еще альфа-версия, и у создателей есть определенный набор нереализованных TODO, и ошибки тоже встречаются (и исправляются).

Уровень подготовки


Перечислю основное, что нужно знать и понимать, чтобы быстро въехать в derby:
  1. базовые знания по веб-разработке (html, css, javascript);
  2. nodejs — нужно понимать commonjs-модули, npm, знать, как запустить стандартный http-сервер;
  3. expressjs — приложения derby строятся поверх приложений express, поэтому хорошо бы иметь об экспресс и серверном js какие-то базовые знания (подключение модулей, обработка запроссов и т.д.)

Есть так же определенный набор технологий, которые используются в derby и знакомство с ними здорово бы помогло (хотя и не является обязательным, мы постепенно будем всего этого касаться)
  1. реактивное программирование
  2. изоморфные javascript приложения
  3. операциональное преобразование — технология, разработанная google, для разрешения конфликтов при одновременном редактировании документов в google docs
  4. browserify
  5. mongodb

Платформа


Нам подойдет linux, mac. C windows могут быть проблемы — версия 0.5 работала нормально и под windows (правда приходилось самому компилить redis версии 2.6), версия 0.6 тоже к этому идет, но есть парочка pull-request-ов, которые еще не попали в основной репозиторий, поэтому начинающим пока стоит подождать.

Перед началом разработки нужно убедиться, что на компьютере установлены:
  1. nodejs
  2. mongodb
  3. redis 2.6 (обратите внимание, версия 2.4 не подходит) — upd redis уже не обязателен

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

Итак, начинаем


Разберем пример: https://github.com/zag2art/derby-example-hello. Он очень простой, зато разъяснений будет много.

Можно скопировать себе готовый пример и изучить его, а можно набить его с нуля самому. Советую второй вариант, так лучше отложится в памяти, но выбирайте сами, я разъяснию оба варианта.

Копируем из моего репозитория:

# делаем себе копию
git clone https://github.com/zag2art/derby-example-hello.git

# заходим в папочку проекта
cd derby-example-hello

# устанавливаем зависимости (там два пакета derby и derby-starter)
npm install

# чтобы запустить нужно будет набрать команду снизу и открыть бруазер на странице localhost:3000
npm start


Создаем все файлы сами (предварительно создав папочку и войдя в нее):

package.json создаем стандартно, используя npm init (в качестве файла запуска указываем server.js), далее добавляем два модуля тоже через npm:

# ставим последнюю версию дерби из ветки 0.6 (если версию не указать npm отдает версию 0.5), сохраняем ее в package.json
npm install derby@~0.6 -S

# ставим derby-starter
npm install derby-starter -S


Несколько слов о derby-starter: скорее всего вы никогда не будете использовать его в своих проектах. Гляньте если хотите его код, здесь по большей части инициализируется стандартное expressjs-приложение, к которому в качестве middle-ware цепляется дерби. Здесь же настраивается подключение дерби к данным (монге и редису), ну и настраивается серверная часть дерби.

В обычном случае этот код будет находится внути дерби-приложения, так как его нужно будет дополнять, например, для подключения авторизации через passport, ограничений доступа к данным через racer-access, или же, если вам захочется обрабатывать часть запросов express-ом, а не дерби (например, если нужен дублирующий restful-api). Но для наших целей всего этого пока не нужно, и, благодаря этому модулю наша серверная часть сокращается до одной строки:

server.js

require('derby-starter').run(__dirname+'/index.js');

Запускаем серверную часть дерби указывая в качетсве параметра путь к файлу index.js, в котором и находтся само наше derbyjs-приложение.

Итак, приложение сотоит из 2-х файлов: index.js

var app = module.exports = require('derby').createApp('hello', __filename);
app.loadViews(__dirname);

// Маршрут рендерится на клиене и на сервере
app.get('/', function(page, model) {
  // Подписка обеспечивает синхронизацию данных
  model.subscribe('hello.message', function() {
    page.render();
  });
});


и index.html

<Body:>
  <!-- в шаблоне прописывается html и привязки к данным -->
  Holler: <input value="{{hello.message}}">
  <h2>{{hello.message}}</h2>


Давайте сначала наберем их, запустим приложение, поиграемся с ним, а потом разберем исходный код. Итак, все файлы находятся в одной папке: package.json, server.js, index.js и index.html. Модули derby и derby-starter установлены и находятся в подкаталоге node_modules, mongo и redis установлены и запущены.

Запускаем приложение (npm start, ну или напрямую — node server.js):

zag2art@laptop:~/work/derby-example-hello$ npm start

> derby-example-hello@0.0.0 start /home/zag2art/work/derby-example-hello
> node server.js

Master pid  11291
11293 listening. Go to: http://localhost:3000/


Открываем браузер, вводим адрес http://localhost:3000/, и пришем что-нибудь в input-е, например:


Что видим, введенный нами текст, повторился в блоке h2, ниже input-а, здесь срабатывают реактивные привязки. Еще один эксперемент, попробуем открыть еще одну вкладку с этим же адресом http://localhost:3000/. Видим, введенный нами ранее текст. То есть данные синхронизируются между вкладками (а если бы наше приложение было выложено в Интернете, то и между абсолютно всеми клиентами). Попробуем поменять данные. Изменение сразу же отразится на соседней вкладке, без каки-либо лишних миганий, то-есть при обновлении данных, нужная часть страницы пересоздается прямо на клиенте. Далее, давайте посмотрим на исходный код страницы на второй вкладке:



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

Теперь давайте разберем принципы, заложенные в derby, а так же исходный код. Первое о чем стоит задуматься — это то, какие требования к системе были у создателей derby:
  1. Дерби, предназначена для создания SPA (сложных, богатых элементами веб-приложений) приложений с сильной перерисовкой внутри страницы
  2. Для удобства пользователей, приложение должно позволять делать закладки на свое текущее состояние — а значит при важном изменении состояния, должен меняться url
  3. То же самое касается и инексации поисковиками. Приложение должно индексироваться, отсюда вытекает, что при проектировании приложения, создатель должен четко для себя решить, какие состояния приложения должны попадать в индекс и запланировать для них соответствующие url.

Итак, создатели поняли следующее, если страница запрашивается у сервера, нужно генерировать ее там и отдавать уже готовой, если же пользователь в браузере работает в приложении он не должен при смене url-каждый раз обращаться к серверу, ждать, получать мелькание экрана. Так же очень не хотелось бы дублировать код рендеринга страницы. То есть нам получается нужно иметь возможность отрисовывать страницу и на сервере и на клиенте, и не дублировать код. И на клиенте и на сервере у нас javascript — это облегчает дело. Но можно ли вообще так сделать. Получается нам нужно, чтобы и на клиенте и на сервере одинаково работал код, отвечающий за рендеринг страниц (шаблонизация, работа с html), маршрутизация (работа с url при смене адреса на клиенте), причем, получается, что и там и там нужно единообразно организовать доступ к данным. Такой код, работающий одинаково и на клиенте и на сервере, называется изоморфным, можете прочитать об этом тут. В дерби это реализовано.

Получается в дерби есть 2 части:
  1. Часть относящаяся только к серверу (всевозможные настройки, подключение модулей, привязка к expressjs). Обратите внимание здесь нет ни рендеринга, ни маршрутизации. В нашем случае это файл server.js c модулем derby-starter.
  2. Само изоморфное приложение. Его код исполняется на сервере, когда запрашивается какая-либо страница с сервера, а дальше, код работает уже на клиента. В нашем случае, это файлы — index.js и index.html.

Давайте я попытаюсь подробней рассказать о второй части. Представим, что мы создали дерби приложение, работающее с 3-мя страницами:
  1. / — домашняя страница сайта
  2. /about — страница с информацией о создателе
  3. /projects — страница с проектами

Все страницы имеют ссылки друг на друга. Как будет работать с таким сайтом поисковик. Он сделает 3 запроса, по одному к каждой странице, и нормально их проиндексирует. Как будет с этим работать пользователь. (обратите внимание — важный момент). Пользователь войдет на сайт (либо по ссылке, либо введя адрес в адресную строку), на любую из этих трех страниц. Это будет единственным запросом к серверу. Потому, что вместе с готовой страницей, пользователь получит в нагрузку все изоморфное приложение (так называемый бандл, включающий в себя в упакованном виде все, что мы написали — js-файлы в которых прописана обработка url, html-файлы с шаблонами, css-файл, а так же часть дерби, которая позволяет всему этому работать). Таким образом, изначально запросив, допустим страницу /about, пользователь получает на клиенте готовое SPA-приложение. И теперь, если он нажмет (на свое страничке about) на ссылку / или /projects — запросов к серверу больше не будет (здесь должна быть звездочка, которую я расшифрую потом). Страница сгенерируется напрямую на клиенте, url в браузере поменяется. Ну и так далее: пользователь может бегать по этим трем страницами, без всяких запросов к серверу.

Так, теперь давайте посмотрим на код index.js:

var app = module.exports = require('derby').createApp('hello', __filename);
app.loadViews(__dirname);

// Маршрут рендерится на клиене и на сервере
app.get('/', function(page, model) {
  // Подписка обеспечивает синхронизацию данных
  model.subscribe('hello.message', function() {
    page.render();
  });
});

Во-первых, нужно сказать, что index.js — это common.js модуль, то-есть, мы, например, легко можем подключить сюда любые модули, которые могут работать, как на клиенте, так и на сервере. Вот, например, так: var _ = require('underscore');. В первой строке подкючается и инициализируется дерби.

app.loadViews(__dirname);

Здесь мы показываем, где у нас находятся файлы с шаблонами. В данном случаем мы указали на ту же папку, в которой лежит index.js, дебри поищет там и найдет index.html. У нас минимальное учебное приложение, поэтому все в одной папке, обычно же шаблоны лежать отдельно в подпапочке views. По идее, если бы у нас были css-стили, здесь же мы бы прописали что-то типа:

// пример из нормального приложения побольше
app.loadViews (path.join(__dirname, '../views'));
app.loadStyles(path.join(__dirname, '../styles'));

Там бы мог находиться, например, файл index.css (ну или index.styl или index.less — дерби их поддерживает). Естественно в этом файле могут быть include-ы со своей структурой подпапок.

Идем дальше, а дальше код обработки url. Схематично, если бы мы делали то приложение, которое я описал (на 3 стараницы) — здесь было бы:

app.get('/', function(page, model) {
  ...
});

app.get('/about', function(page, model) {
  ...
});

app.get('/projects', function(page, model) {
  ...
});

Понятно, да? На все, что мы назвали отдельной страницей, здесь должен быть обработчик (кто-то скажет контроллер). Да, еще стоит упомянуть то, что все дело очень похоже на expressjs, здесь можно использовать параметры, например:

app.get('/users/:user', getUser);

Подробней смотрите здесь

Что делаем внутри обработчика? Вообще по аналогии с expressjs мы должны подготовить данные для рендеринга страницы, а потом вызвать функцию render с соответствующим шаблоном и данными в качестве параметров. Схема здесь та же, но есть и свои особенности. Сначала разберемся с данными. Для работы с ними используется model (передается в обработчик параметром). Дерби — реактивный фреймворк, поэтому у нас при работе с данными всегда есть два варианта: либо мы просто получаем данные, такими какие они есть да данный момент и отдаем их дальше шаблонизатору, либо же мы их получаем, но, при этом, еще и подписываемся на их обновление… Что это значит. Преставим себе страницу с каким-нибудь списком: если мы просто получили и вывели данные, то все — страница будет статично, если же мы еще и подписались на обновления, то список на нашей странице будет обновляться (если, например, другой пользователь, имеющий доступ к данному списку, поменял его). В коде это выглядет примерно так:

// подтягиваем данные без подписки на обновление
model.fetch('list', function(){
  // Здесь данные уже подтянуты
  // Можно вызывать render
});

// подтягиваем данные c подпиской на обновление
model.subscribe('list', function(){
  // Здесь данные уже подтянуты, 
  // подписка на будущие обновления зарегистрирована
  // Можно вызывать render
});

Итак, код из нашего примера:
  model.subscribe('hello.message', function() {
    page.render();
  });

Мы подписываемя на 'hello.message', и в функции обратного вызова (когда данные подтянуты) вызываем render. Здесь возникает несоколько вопросов: что такое 'hello.message' и почему render без параметров (нет ни имени шаблона, ни данных)?

В дерби за работу с реактивными данными отвечает модуль racer, в котором все обращения к данным происходят с использованием так называемых «путей». У нас 'hello.message' — это путь, где 'hello' — это имя коллекции в mongo (в sql была бы таблица), 'message' — это id записи в коллекции. То-есть мы здесь подписались на одну единственную запись в коллекции hello. Именно эти данные и будут попадать в наш input в шаблоне. Подробнее о работе с данными и путях смотрите тут.

Далее, в render мы ничего не передали по следующим причинам: html для url=/ у нас задан в главном html-файле (index.html — корневой, могло бы быть еще несколько, подключенных к нему через import), он будет исползован по умолчанию, а данные мы не передали, потому что в шаблонах есть доступ к «путям».

Теперь файл с шаблонами — index.html:
<Body:>
  <!-- в шаблоне прописывается html и привязки к данным -->
  Holler: <input value="{{hello.message}}">
  <h2>{{hello.message}}</h2>

Итак, сам файл состоит из нескольких секций (у нас только одна — Body), в терминологии дерби, они и называются шаблонами. То есть так: у нас есть файл шаблонов, в котором есть шаблон Body, как вы понимаете, все что мы в него положили, окажется в body результирующего html. В рамках данного примера, я не буду вам объяснять всю систему шаблонизации дерби, включая пространства имен, наследование и т.д. (пример неподходящий), добавлю лишь несколько моментов. В двойных фигурных скобках — привязки к данным (те самые наши пути). Для задания title страницы, например, мы могли бы воспользоваться еще одним предопределенным шаблоном Title, например, так:
<Title:>
  Мое первое дерби-приложение
<Body:>
  <!-- в шаблоне прописывается html и привязки к данным -->
  Holler: <input value="{{hello.message}}">
  <h2>{{hello.message}}</h2>

Внутри шаблонизатор очень похож на handlebars. Приведу несколько примеров для наглядности (не стоит в них вдумываться особо):

<Body:>
  {{if _page.login}}
    <h3> Hello, friend! </h3>
  {{/}}  

  {{each _page.todos as #todo, #index}}
    <p>{{#todo.text}}</p>
    {{if #index % 5 === 0}}
        <!-- 0, 5, 10, 15 -->
        <b>Важно</b>
    {{/}}
  {{/}}

Ну и пример привязки к событиям:

  <a href="#" on-click="{{removeTopic(topic[#index])}}">Ok</a>

Здесь мы забежали немножко вперед, но думаю это оправдано. На следующей неделе, сделаем «список дел» (TODO-list), там все это будет использовано и объяснено.

А пока поиграйтесь с кодом, попробуйте добавить, что-нибудь в шаблон, поменяйте title (обратите внимание дерби поддерживает livereloading, то есть как только вы измените html-файл и запишите изменение — браузер сам обновит страницу). Попробуйте подключить стили.

P. S.
Если вам захочется почитать стандартную документацию по дерби, имейте ввиду, что она написана под версию 0.5, некоторые части там неактуальны.
Что там читать можно: контроллеры, модели. Что не стоит: представления, шаблоны, компоненты — все уже поменялось, вы только запутаетесь.

P. P. S.
В комментариях, пожалуйста, напишите, о чем бы вы хотели услышать по derby. Что наиболее интересно? Может быть есть какие-то вопросы? Если есть — задавайте их полюбому, важно заложить прочную основу.

update
Второй пример — http://habrahabr.ru/post/221703/
Третий пример — http://habrahabr.ru/post/222399/

Если нравится derbyjs — не сочтите за труд поставить звездочку на github

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Интересна ли тема, стоит ли продолжать серию?

Поделиться публикацией

Похожие публикации

Комментарии 42

    +1
    Интересно было бы услышать минусующих… Вроде бы статья в духе хабра — энтузиаст делится знаниями. Или дело в формате?
      0
      Ну на Хабре была уже серия туториалов по Дерби, может из-за этого минусуют.
        +4
        Может быть, я читал, но, ИМХО, она не раскрывала до конца сути дерби. И немножко не хватало системности.
        0
        Недовольные существуют при любой ситуации.
        На них не стоит обращать внимание.
          +2
          Да, замысел хороший, важно не скатиться к повествованию в стиле того первого автора: habrahabr.ru/post/196088/.
            +1
            Не стреляйте в пианиста, играет как умеет.
              0
              Да не, Володь. Молодец, однозначно. Многие бы про дебри без твоих статей и не услышали бы.
          +1
          Вопросы (я понимаю, что можно в документации прочитать, но раз уж вы вызвались отвечать).
          1) В примере нет моделей, шаблон отрисовывает данные по plain js объекту, взятому напрямую из Mongo. Я так понимаю, нормальные модели всё-таки есть? Бизнес-логику в них реализовывать можно?
          2) Какой механизм «реактивного» взаимодействия? На уровне протокола. Сокеты, лонг-поллинг, что-то там ещё?
            0
            Завтра вам подробно отвечу.
              0
              1. В самом derby слоя, абстрагирующего модель, нет (как я понимаю, вы говорите о чем-то вроде монгуса для монги), но есть сторонние модули, например racer-mw. Сам не использовал, сказать больше не могу.

              2. Для взаимодействия в штатной поставке используется browserchannel. Это аналог socket.io от google (основанный на лонг-поллинг), используемый ими, например, в gmail. По информации от создателей дерби (кто-то из них работал в google) он стабильней socket.io, в частности, жестко гарантирует порядок получения сообщений и отсутствие сообщений после разрыва соединения. Но, используя этот модуль, можно заменить browserchannel на любую нужную вам технологию (Engine.IO, WebSockets, SockJS, Socket.IO). Ну, например, если для горизонтального масштабирования вам нужна поддержка стики-сессий в хероку.
            • НЛО прилетело и опубликовало эту надпись здесь
                +1
                Да, конечно. Наверное, добрая половина постов про метеор на хабре — моя. С него я на дерби и перешел. В сам момент перехода — это было скорее стечение обстоятельств (искал проекты на метеоре или дерби, чтобы поучаствовать — нашел на дерби).

                Но, по своим ощущениям, могу сказать, что дерби мне ближе. Устройство: все модули — commonjs, отсюда все через npm, концепция изоморфного приложения мне близка, радует серверный рендеринг, а не костыли, как в метеоре. Никто сюда не прибивал костылей для работы с асинхронностью — выбирай что больше нравится. Browserify — для создания бандлов — мне сам по себе нравится этот инструмент.

                Но, есть и недостатки, Их два. Отсутствие документации (пытаюсь это поправить) и отсутствие кучи модулей (как кажется в сравнении с метеором). Но, если вдуматься, получается, что второй недостаток 90% надуманный. Метеору куча модулей нужны именно из-за того, что они пошли по пути отхода от npm (часто делаются обертки над существующими npm-модулями). В дерби же, являясь надстройкой над express, и, одновременно, обычным npm-модулем, проблем с этим нет. Здесь можно использовать все.
                  0
                  ДВА?? (-:
                    0
                    Имхо, конечно.
                      0
                      Конечно (-:
                      А минусуют за то, что это миллион+первый пост о том, как поставить и запустить минимальное приложение на дерби.
                      До тех пор, пока посты о дерби будут этим ограничиваться, шансы на популяризацию и новых адептов минимальны.
                      Разбор примеров — это прекрасно, но если этим ограничится всё — из прочитавших эти статьи и сотая часть не начнёт писать на дерби.
                        0
                        А чего бы хотелось?
                          0
                          Ну я же уже миллион раз это говорил (-:
                          — аутентификация (включая регистрацию, подтверждение по мылу, сброс/восстановление пароля, социалки, доступ и добавление информации к пользователю, избегание дубликатов)
                          — авторизация (ограничение на запись/обновление, но не чтение, доступ к полям, а не записям)
                          — валидация
                          — локальный поиск (geo, например)
                          — горизонтальное масштабирование
                          Могу много чего ещё набросать (-:

                          Если уж ветвь комментов пошла от сравнения с метеором, то тогда бы хоть какой-то пример, сродни примеру «Вечеринок» у того же метеора… Уж куда элементарнее, но там есть и пользователи, и разграничение прав, и много чего ещё…
                            0
                            Там вроде redis под капотом, оно скейлится на уровне «нифига».
                              0
                              Ну почему же… работает как-то у людей… просто без этих во многом элементарных вещей фреймворк, как бы это помягче сказать, бесполезен…
                                0
                                ну «работает как-то» это не скейлится.
                                  0
                                  Не поспоришь (-:
                                0
                                Теперь можно без redis-а. Сегодня вышла livedb версии 0.4. Редис стал необязательным, так же добавились проекции (возможность подписываться только на часть документа — только на определенные поля)
                                  0
                                  спасибо
                  0
                  Тоже сейчас разбираюсь с Derby.js и меня очень заботит один вопрос: Я отделил часть логики от самого derby приложения, дабы она не была доступна на клиенте (по принципу как дерби подключает разные скрипты на клиенте и сервере, только у меня без клиентской версии). И теперь у меня проблема, как организовать прозрачное взаимодействие логики которая находится в derby (то есть и на клиенте и на сервере может выполнятся) и той которая находится только на серверной стороне.

                  Как вариант пока вижу создавать в модели объекты Request и Response и соответственно подписаться на них со всех сторон.
                    0
                    Поделюсь своим опытом. В одном из проектов, мы делаем экономические игры для университетов, готовящих студентов про программа MBA. Так вот, типичная игра выглядит так: есть профессор и 30-60 студентов. Профессор запускает игру, студенты читают правила, формулы подсказки — потом играют вводя данные. Например, симулируется рынок: студенты — это конкурирующие компании, выпускающие аналогичный продукт, в течении нескольких раундов они выставляют цену на свой продукт, большую прибыль получает тот, что выставил меньшую центу (понятно, там всякие сложные формулы, и теория, ну да ладно)

                    Итак, как это происходит в игре. Когда игра стартует и начинается первый раунд, студенты вводят свое значение цены на продукт. Профессор, после того, как все все ввели жмет кнопку: «следующий раунд». В этот момент посылает post-запрос AJAX-ом на сервер, там он обрабатывается экспрессом (не дерби), где и отрабатывает вся логика расчетов и перехода на следующий раунд. Вот как схематично выглядит такой обработчик:

                    expressApp.post('/api/:gameId', function(req, res){
                      var model = req.getModel();
                      ..... логика
                      // меняю значение раунда у игры, через model.set
                      res.ajax(true);
                    });
                    


                    А у клиентов (как у игроков, так и у профессора) есть подписка на изменение раунда model.on("change", "_page.game.round", oldValue, newValue, function(){});

                    Таким образом, вся логика на сервере и скрыта от клиентов, и они вовремя получают уведомление о том, что она отработала.
                      0
                      А как к ней обращатся с серверной стороны? Тоже аяксом?
                        0
                        Мы с вами что-то запутались. Опишите свою ситуацию точнее, я предложу решение.
                          0
                          Как пример класс для работы с api стороннего сервиса, с авторизацией логин + пароль или ключи. Вот и хотелось бы иметь человеческий интерфейс для вызова таких функций. Что то в духе того как это сделано в Racer. Вот даже диаграммку набросал pastexen.com/i/GKFephWWSw.png
                            +1
                            Если запросы могут идти и с клиента и из сервера (то-есть из любой части derby-приложения), используйте: https://github.com/rma4ok/racer-server-request
                              0
                              Супер, это именно то что нужно.
                    0
                    А когда планируется релиз 0.6? На офсайте до сих пор про нее ни слова.
                      0
                      Судя по тому, как все движется. Думаю, месяца через 4.
                      0
                      На сервере и на клиенте доступность данных одинаковая? Можно ли с клиента (как на сервере) использовать любые запросы к источнику данных?
                        0
                        В нашем примере — да, но можно накладывать ограничения, на чтение/запись и т.д.
                          0
                          Хм, фактически писать SQL запросы с клиента? Или должно создаваться API строго под проект, которое будет использоваться изоморфными компонентами? Вопрос даже не про derby, а в целом по изоморфным приложениями. В каком месте граница изоморфности?
                            0
                            Фактически — да, писать mongo-db запросы на клиенте, которые смогут тянуть только те данные, которые доступны. Границы, например в derby и метеоре разные. В дерби изоморфная часть — это роутер, рендеринг, подписка на данные. Настройка доступа к данным, подключение всяких скриптов клиентских (ну и вообще формирование бандла) — это все серверные задачи. Так же нужно понимать, что даже, не смотря на то, что всевозможные event-handler-ы и входят в derby-приложение (которое изоморфно), срабатывать они будут только на клиенте (я имею ввиду всякие on-click и т.д.). В метеоре, же, например, рендеринг сейчас полностью клиентский — здесь другие границы.
                              0
                              Меня вот что волнует: если ограничения к данным накладываются правами доступа, то серверу придется обрабатывать любые сложные запросы. Что можно применить для атаки. Если ограничения делаются программным интерфейсом, то разработка изоморфных компонентов будет зависеть от него (от разработки API). Какой вариант предпочтителен из вашего опыта?
                                0
                                Думаю, в общем случае, выбор варианта зависит от задач (нужна ли нам гибкость запросов / производительность ). В случае с mongodb, фильтрация запросов очень даже оправдана, ведь mongodb — документоориентированная база. Она очень сильно отличается от SQL например тем, что не поддерживает join-ы и т.д. Всегда можно точно сказать, что вот эти таблички можно только читать, вот эти править, а вот в этой пользователь может править только свои записи. Подавляющее большинство запросов в mongo идет к какой-то одной конкретной табличке (коллекции в их терминологии), и все можно быстро отфильтровать.
                        0
                        Сайт и блог зависли на версии 0.5, подскажите:
                        1) нужно что то настраивать чтобы работало без redis?
                        2) если ставить с redis какая от этого выгода?
                        3) Где следить за изменениями в ветке 0.6?
                          0
                          1. для создания каркаса приложения на 0.6 используйте https://github.com/derbyparty/generator-derby. Там можно выбрать с redis-ом или без.

                          2. главное, что дает redis — это возможность горизонтального масштабирования (можно запустить несколько derby-серверов для одного сайта). Но это можно будет включить и потом. Для начала без redis-а — самое то.

                          3. на github, обсуждение на русском (хотя там и много оффтопика), на английском
                            0
                            в sharejs 0.7beta используется livedb4.0, которая по умолчанию без redis (однако его можно включить)
                              0
                              а derby под капотом использует sharejs.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое