Новости DerbyJS 09.2014

В этой статье описаны последние события, связанные с Derby. Так же поделюсь мыслями и полезными ссылками.

Lever

Lever ^[1] — компания, создавшая Derby, прошла очередной (второй ли, третий ли?) раунд инвестиций и обеспечила себе стабильное существование, как минимум, на ближайшие два года. С чем их и поздравляем.
Так же, после того, как вышла Derby 0.6, Lever прикладывает определенные усилия к продвижению фреймворка:

• каждый четверг в 9 am PST (8 pm по Москве) проводятся видео конференции. Анонсы и ссылки на google hangout ловите в google groups рассылке ^[2] (называется Office Hours). Мы попросили проводить именно в такое время, потому что много русских. Обычно конференции ведет Ian ^[3] (разработчик Lever), часто можно видеть Nate ^[4] (CEO Lever, создатель Derby) и Joseph ^[5] (создатель ShareJS). Задаются глупые и умные вопросы, обсуждаются концепции и планы, все делятся мыслями и опытом. Присоединяйтесь. Записи прошедших видео-конференций с кратким описанием основных тем можно посмотреть в блоге Левер ^[6].
• обновился дизайн сайта ^[7]. Теперь там есть добротный FAQ (в том числе и на русском) и ссылки на полезные ресурсы. Единственное чего не хватает (и это главная проблема в данный момент) — документации для 0.6. Workaround: для Racer актуальна документация 0.5 ^[8], а серия статей zag2art ^[9] (начиная с этой ^[10]) покроет значительную часть документации для Derby 0.6.
• участие в конференциях: Джозеф был на ForwardJS ^[11] (к сожалению не нашел видео). Изначально должен был идти Нэйт и рассказать про тонкости и проблемы Agnostic Rendering (шаблонизатор, работающий и на клиенте и на сервере), но почему-то не смог, надеюсь еще услышим этот доклад. Ян был на JS встрече ^[12] в Сан-Франциско.

Github

Derby переехал в новую группу ^[13]. Это связанно с тем, что в старой накопилось много хлама и название Codeparty не отображало суть.
Активная часть сообщества создала свою группу ^[14], где потихоньку пилятся модули.
Lever тоже выкладывает свои наработки ^[15]. Еще стоит обратить внимание на наработки компании Decision Mapper ^[16].

Сообщество

Сообщество медленно, но верно прибывает. Часто путь выглядит так: клиентский фреймворк (AngularJS, Ember и тп) -> Meteor ^[17] -> Derby. Метеор хорошо помогает проникнуться концепциями realtime, full-stack, бд на клиенте, изоморфность и тп, но не удовлетворяет всех в силу тех или иных причин. Вообще, вот тут ^[18] Нэйт очень интересно рассказал про основные фреймворки.
Недавно создали чат на Gitter ^[19].

Идеи

Есть несколько мыслей, по поводу того, что можно добавить или изменить в Derby:

Использование FoundationDB ^[20] в качестве хранилища.

В текущей реализации livedb ^[21] события на изменение документов ловятся за счёт Redis pub-sub (для одного node процесса, можно без Redis). И это часть функциональности является встроенной. Для хранения лога операций (oplog) и текущих версий документов (snapshots) используется внешний драйвер, который можно написать, в общем, для любой бд, например, для Mongo ^[22].

Проблемы в текущей реализации:
— использование двух бд, вместо одной.
— использование последовательного выполнения однопоточных Lua-скриптов в качестве альтернативы транзакциям, приводит к тому, что Redis потенциально становится узким местом (хотя пока никто с этим не столкнулся). Так же теоретически, при высокой коллаборации (много клиентов, обслуживающиеся разными node процессами, изменяют один документ) Redis'у потребуется значительно больше, чем одна попытка применить операцию к данным, так как текущая версия данных будет меняться от операциий других node процессов, что может повлиять на производительность (тут тоже проблем ни у кого пока не было).
— для случаев, когда клиент подписан на отсортированный запрос к коллекции (Query), нету возможности дешево понять как изменение очередного документа повлияет на его положение в данной query. В данный момент это делается довольно топорным способом: запрос применяется к коллекции, достаются все документы для этого запроса, высчитывается разница и отправляется на клиент (для приложений с большим количеством таких запросов это вызывает проблемы с производительностью). В данном случае проблема могла бы быть решена с помощью событий на изменение индекса в бд. К сожалению, бд с событиями на изменение индекса нет (если знаете, поделитесь). Наверно это не так трудно добавить в большинство бд, но никогда не было нужды (как вариант, можно попросить добавить это в Монгу).

FoundationDB имеет Pub-Sub и может заменить и Redis, и Mongo. Наличие встроенных транзакций упростит логику применение операций.
Также поверх FoundationDB можно написать свой Document Model слой, например fowl ^[23], в котором реализовать события на изменения индексов. Такой адаптер решит проблему отсортированных query.

Минусы FoundationDB — закрытость исходников, не бесплатность.

Джозеф уже наваял livedb-foundation ^[24]. Дело за адаптером.

Клиентский кэш

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

Derby/ShareJS представляется хорошей платформой для этого. Всё что нужно синхронизировать данные в модели с IndexedDB, научить Derby сначала искать данные в клиентском кэше, а потом (если доступен сервер) запрашивать с него разницу (новые версии). Также нужно при офлайне хранить операции в IndexedDB, и отправлять их на сервер при появлении соединения.

Access-control

Первый модуль access-control — racer-access ^[25] имеет уязвимости с доступом по queries и в данный момент не рекомендован к использованию. В данный момент рекомендуется осуществлять контроль доступа на уровне ShareJS вручную ^[26] или с помощью модуля share-access ^[27].

Есть идея совместить модуль валидации и access-control, добавив в схемы racer-schema ^[28] подобие Firebase Security ^[29].

Послесловие

Всем, у кого есть вопросы по Derby/Racer/ShareJS, пишите мне на скайп vmakhaev.
Не пропустите Open Hours меньше, чем через час. Удачи!

Автор: vmakhaev

Источник ^[30]