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

Ну на Хабре была уже серия туториалов по Дерби, может из-за этого минусуют.

Недовольные существуют при любой ситуации.
На них не стоит обращать внимание.

Да, замысел хороший, важно не скатиться к повествованию в стиле того первого автора: habrahabr.ru/post/196088/.

Завтра вам подробно отвечу.

1. В самом derby слоя, абстрагирующего модель, нет (как я понимаю, вы говорите о чем-то вроде монгуса для монги), но есть сторонние модули, например racer-mw. Сам не использовал, сказать больше не могу.

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

Да, конечно. Наверное, добрая половина постов про метеор на хабре — моя. С него я на дерби и перешел. В сам момент перехода — это было скорее стечение обстоятельств (искал проекты на метеоре или дерби, чтобы поучаствовать — нашел на дерби).

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

Но, есть и недостатки, Их два. Отсутствие документации (пытаюсь это поправить) и отсутствие кучи модулей (как кажется в сравнении с метеором). Но, если вдуматься, получается, что второй недостаток 90% надуманный. Метеору куча модулей нужны именно из-за того, что они пошли по пути отхода от npm (часто делаются обертки над существующими npm-модулями). В дерби же, являясь надстройкой над express, и, одновременно, обычным npm-модулем, проблем с этим нет. Здесь можно использовать все.

Поделюсь своим опытом. В одном из проектов, мы делаем экономические игры для университетов, готовящих студентов про программа 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(){});

Таким образом, вся логика на сервере и скрыта от клиентов, и они вовремя получают уведомление о том, что она отработала.

Судя по тому, как все движется. Думаю, месяца через 4.

В нашем примере — да, но можно накладывать ограничения, на чтение/запись и т.д.

1. для создания каркаса приложения на 0.6 используйте https://github.com/derbyparty/generator-derby. Там можно выбрать с redis-ом или без.

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

3. на github, обсуждение на русском (хотя там и много оффтопика), на английском

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