Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Интересно было бы услышать минусующих… Вроде бы статья в духе хабра — энтузиаст делится знаниями. Или дело в формате?
Ну на Хабре была уже серия туториалов по Дерби, может из-за этого минусуют.
Недовольные существуют при любой ситуации.
На них не стоит обращать внимание.
На них не стоит обращать внимание.
Да, замысел хороший, важно не скатиться к повествованию в стиле того первого автора: habrahabr.ru/post/196088/.
Вопросы (я понимаю, что можно в документации прочитать, но раз уж вы вызвались отвечать).
1) В примере нет моделей, шаблон отрисовывает данные по plain js объекту, взятому напрямую из Mongo. Я так понимаю, нормальные модели всё-таки есть? Бизнес-логику в них реализовывать можно?
2) Какой механизм «реактивного» взаимодействия? На уровне протокола. Сокеты, лонг-поллинг, что-то там ещё?
1) В примере нет моделей, шаблон отрисовывает данные по plain js объекту, взятому напрямую из Mongo. Я так понимаю, нормальные модели всё-таки есть? Бизнес-логику в них реализовывать можно?
2) Какой механизм «реактивного» взаимодействия? На уровне протокола. Сокеты, лонг-поллинг, что-то там ещё?
Завтра вам подробно отвечу.
1. В самом derby слоя, абстрагирующего модель, нет (как я понимаю, вы говорите о чем-то вроде монгуса для монги), но есть сторонние модули, например racer-mw. Сам не использовал, сказать больше не могу.
2. Для взаимодействия в штатной поставке используется browserchannel. Это аналог socket.io от google (основанный на лонг-поллинг), используемый ими, например, в gmail. По информации от создателей дерби (кто-то из них работал в google) он стабильней socket.io, в частности, жестко гарантирует порядок получения сообщений и отсутствие сообщений после разрыва соединения. Но, используя этот модуль, можно заменить browserchannel на любую нужную вам технологию (Engine.IO, WebSockets, SockJS, Socket.IO). Ну, например, если для горизонтального масштабирования вам нужна поддержка стики-сессий в хероку.
2. Для взаимодействия в штатной поставке используется browserchannel. Это аналог socket.io от google (основанный на лонг-поллинг), используемый ими, например, в gmail. По информации от создателей дерби (кто-то из них работал в google) он стабильней socket.io, в частности, жестко гарантирует порядок получения сообщений и отсутствие сообщений после разрыва соединения. Но, используя этот модуль, можно заменить browserchannel на любую нужную вам технологию (Engine.IO, WebSockets, SockJS, Socket.IO). Ну, например, если для горизонтального масштабирования вам нужна поддержка стики-сессий в хероку.
Да, конечно. Наверное, добрая половина постов про метеор на хабре — моя. С него я на дерби и перешел. В сам момент перехода — это было скорее стечение обстоятельств (искал проекты на метеоре или дерби, чтобы поучаствовать — нашел на дерби).
Но, по своим ощущениям, могу сказать, что дерби мне ближе. Устройство: все модули — commonjs, отсюда все через npm, концепция изоморфного приложения мне близка, радует серверный рендеринг, а не костыли, как в метеоре. Никто сюда не прибивал костылей для работы с асинхронностью — выбирай что больше нравится. Browserify — для создания бандлов — мне сам по себе нравится этот инструмент.
Но, есть и недостатки, Их два. Отсутствие документации (пытаюсь это поправить) и отсутствие кучи модулей (как кажется в сравнении с метеором). Но, если вдуматься, получается, что второй недостаток 90% надуманный. Метеору куча модулей нужны именно из-за того, что они пошли по пути отхода от npm (часто делаются обертки над существующими npm-модулями). В дерби же, являясь надстройкой над express, и, одновременно, обычным npm-модулем, проблем с этим нет. Здесь можно использовать все.
Но, по своим ощущениям, могу сказать, что дерби мне ближе. Устройство: все модули — commonjs, отсюда все через npm, концепция изоморфного приложения мне близка, радует серверный рендеринг, а не костыли, как в метеоре. Никто сюда не прибивал костылей для работы с асинхронностью — выбирай что больше нравится. Browserify — для создания бандлов — мне сам по себе нравится этот инструмент.
Но, есть и недостатки, Их два. Отсутствие документации (пытаюсь это поправить) и отсутствие кучи модулей (как кажется в сравнении с метеором). Но, если вдуматься, получается, что второй недостаток 90% надуманный. Метеору куча модулей нужны именно из-за того, что они пошли по пути отхода от npm (часто делаются обертки над существующими npm-модулями). В дерби же, являясь надстройкой над express, и, одновременно, обычным npm-модулем, проблем с этим нет. Здесь можно использовать все.
ДВА?? (-:
Имхо, конечно.
Конечно (-:
А минусуют за то, что это миллион+первый пост о том, как поставить и запустить минимальное приложение на дерби.
До тех пор, пока посты о дерби будут этим ограничиваться, шансы на популяризацию и новых адептов минимальны.
Разбор примеров — это прекрасно, но если этим ограничится всё — из прочитавших эти статьи и сотая часть не начнёт писать на дерби.
А минусуют за то, что это миллион+первый пост о том, как поставить и запустить минимальное приложение на дерби.
До тех пор, пока посты о дерби будут этим ограничиваться, шансы на популяризацию и новых адептов минимальны.
Разбор примеров — это прекрасно, но если этим ограничится всё — из прочитавших эти статьи и сотая часть не начнёт писать на дерби.
А чего бы хотелось?
Ну я же уже миллион раз это говорил (-:
— аутентификация (включая регистрацию, подтверждение по мылу, сброс/восстановление пароля, социалки, доступ и добавление информации к пользователю, избегание дубликатов)
— авторизация (ограничение на запись/обновление, но не чтение, доступ к полям, а не записям)
— валидация
— локальный поиск (geo, например)
— горизонтальное масштабирование
Могу много чего ещё набросать (-:
Если уж ветвь комментов пошла от сравнения с метеором, то тогда бы хоть какой-то пример, сродни примеру «Вечеринок» у того же метеора… Уж куда элементарнее, но там есть и пользователи, и разграничение прав, и много чего ещё…
— аутентификация (включая регистрацию, подтверждение по мылу, сброс/восстановление пароля, социалки, доступ и добавление информации к пользователю, избегание дубликатов)
— авторизация (ограничение на запись/обновление, но не чтение, доступ к полям, а не записям)
— валидация
— локальный поиск (geo, например)
— горизонтальное масштабирование
Могу много чего ещё набросать (-:
Если уж ветвь комментов пошла от сравнения с метеором, то тогда бы хоть какой-то пример, сродни примеру «Вечеринок» у того же метеора… Уж куда элементарнее, но там есть и пользователи, и разграничение прав, и много чего ещё…
Там вроде redis под капотом, оно скейлится на уровне «нифига».
Ну почему же… работает как-то у людей… просто без этих во многом элементарных вещей фреймворк, как бы это помягче сказать, бесполезен…
Теперь можно без redis-а. Сегодня вышла livedb версии 0.4. Редис стал необязательным, так же добавились проекции (возможность подписываться только на часть документа — только на определенные поля)
Тоже сейчас разбираюсь с Derby.js и меня очень заботит один вопрос: Я отделил часть логики от самого derby приложения, дабы она не была доступна на клиенте (по принципу как дерби подключает разные скрипты на клиенте и сервере, только у меня без клиентской версии). И теперь у меня проблема, как организовать прозрачное взаимодействие логики которая находится в derby (то есть и на клиенте и на сервере может выполнятся) и той которая находится только на серверной стороне.
Как вариант пока вижу создавать в модели объекты Request и Response и соответственно подписаться на них со всех сторон.
Как вариант пока вижу создавать в модели объекты Request и Response и соответственно подписаться на них со всех сторон.
Поделюсь своим опытом. В одном из проектов, мы делаем экономические игры для университетов, готовящих студентов про программа MBA. Так вот, типичная игра выглядит так: есть профессор и 30-60 студентов. Профессор запускает игру, студенты читают правила, формулы подсказки — потом играют вводя данные. Например, симулируется рынок: студенты — это конкурирующие компании, выпускающие аналогичный продукт, в течении нескольких раундов они выставляют цену на свой продукт, большую прибыль получает тот, что выставил меньшую центу (понятно, там всякие сложные формулы, и теория, ну да ладно)
Итак, как это происходит в игре. Когда игра стартует и начинается первый раунд, студенты вводят свое значение цены на продукт. Профессор, после того, как все все ввели жмет кнопку: «следующий раунд». В этот момент посылает post-запрос AJAX-ом на сервер, там он обрабатывается экспрессом (не дерби), где и отрабатывает вся логика расчетов и перехода на следующий раунд. Вот как схематично выглядит такой обработчик:
А у клиентов (как у игроков, так и у профессора) есть подписка на изменение раунда
Таким образом, вся логика на сервере и скрыта от клиентов, и они вовремя получают уведомление о том, что она отработала.
Итак, как это происходит в игре. Когда игра стартует и начинается первый раунд, студенты вводят свое значение цены на продукт. Профессор, после того, как все все ввели жмет кнопку: «следующий раунд». В этот момент посылает 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(){});Таким образом, вся логика на сервере и скрыта от клиентов, и они вовремя получают уведомление о том, что она отработала.
А как к ней обращатся с серверной стороны? Тоже аяксом?
Мы с вами что-то запутались. Опишите свою ситуацию точнее, я предложу решение.
Как пример класс для работы с api стороннего сервиса, с авторизацией логин + пароль или ключи. Вот и хотелось бы иметь человеческий интерфейс для вызова таких функций. Что то в духе того как это сделано в Racer. Вот даже диаграммку набросал pastexen.com/i/GKFephWWSw.png
Если запросы могут идти и с клиента и из сервера (то-есть из любой части derby-приложения), используйте: https://github.com/rma4ok/racer-server-request
А когда планируется релиз 0.6? На офсайте до сих пор про нее ни слова.
На сервере и на клиенте доступность данных одинаковая? Можно ли с клиента (как на сервере) использовать любые запросы к источнику данных?
В нашем примере — да, но можно накладывать ограничения, на чтение/запись и т.д.
Хм, фактически писать SQL запросы с клиента? Или должно создаваться API строго под проект, которое будет использоваться изоморфными компонентами? Вопрос даже не про derby, а в целом по изоморфным приложениями. В каком месте граница изоморфности?
Фактически — да, писать mongo-db запросы на клиенте, которые смогут тянуть только те данные, которые доступны. Границы, например в derby и метеоре разные. В дерби изоморфная часть — это роутер, рендеринг, подписка на данные. Настройка доступа к данным, подключение всяких скриптов клиентских (ну и вообще формирование бандла) — это все серверные задачи. Так же нужно понимать, что даже, не смотря на то, что всевозможные event-handler-ы и входят в derby-приложение (которое изоморфно), срабатывать они будут только на клиенте (я имею ввиду всякие on-click и т.д.). В метеоре, же, например, рендеринг сейчас полностью клиентский — здесь другие границы.
Меня вот что волнует: если ограничения к данным накладываются правами доступа, то серверу придется обрабатывать любые сложные запросы. Что можно применить для атаки. Если ограничения делаются программным интерфейсом, то разработка изоморфных компонентов будет зависеть от него (от разработки API). Какой вариант предпочтителен из вашего опыта?
Думаю, в общем случае, выбор варианта зависит от задач (нужна ли нам гибкость запросов / производительность ). В случае с mongodb, фильтрация запросов очень даже оправдана, ведь mongodb — документоориентированная база. Она очень сильно отличается от SQL например тем, что не поддерживает join-ы и т.д. Всегда можно точно сказать, что вот эти таблички можно только читать, вот эти править, а вот в этой пользователь может править только свои записи. Подавляющее большинство запросов в mongo идет к какой-то одной конкретной табличке (коллекции в их терминологии), и все можно быстро отфильтровать.
Сайт и блог зависли на версии 0.5, подскажите:
1) нужно что то настраивать чтобы работало без redis?
2) если ставить с redis какая от этого выгода?
3) Где следить за изменениями в ветке 0.6?
1) нужно что то настраивать чтобы работало без redis?
2) если ставить с redis какая от этого выгода?
3) Где следить за изменениями в ветке 0.6?
1. для создания каркаса приложения на 0.6 используйте https://github.com/derbyparty/generator-derby. Там можно выбрать с redis-ом или без.
2. главное, что дает redis — это возможность горизонтального масштабирования (можно запустить несколько derby-серверов для одного сайта). Но это можно будет включить и потом. Для начала без redis-а — самое то.
3. на github, обсуждение на русском (хотя там и много оффтопика), на английском
2. главное, что дает redis — это возможность горизонтального масштабирования (можно запустить несколько derby-серверов для одного сайта). Но это можно будет включить и потом. Для начала без redis-а — самое то.
3. на github, обсуждение на русском (хотя там и много оффтопика), на английском
в sharejs 0.7beta используется livedb4.0, которая по умолчанию без redis (однако его можно включить)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучаем Derby 0.6, пример #1