В этой статье описаны последние события, связанные с Derby. Так же поделюсь мыслями и полезными ссылками.
Lever
Lever — компания, создавшая Derby, прошла очередной (второй ли, третий ли?) раунд инвестиций и обеспечила себе стабильное существование, как минимум, на ближайшие два года. С чем их и поздравляем.
Так же, после того, как вышла Derby 0.6, Lever прикладывает определенные усилия к продвижению фреймворка:
- каждый четверг в 9 am PST (8 pm по Москве) проводятся видео конференции. Анонсы и ссылки на google hangout ловите в google groups рассылке (называется Office Hours). Мы попросили проводить именно в такое время, потому что много русских. Обычно конференции ведет Ian (разработчик Lever), часто можно видеть Nate (CEO Lever, создатель Derby) и Joseph (создатель ShareJS). Задаются глупые и умные вопросы, обсуждаются концепции и планы, все делятся мыслями и опытом. Присоединяйтесь. Записи прошедших видео-конференций с кратким описанием основных тем можно посмотреть в блоге Левер.
- обновился дизайн сайта. Теперь там есть добротный FAQ (в том числе и на русском) и ссылки на полезные ресурсы. Единственное чего не хватает (и это главная проблема в данный момент) — документации для 0.6. Workaround: для Racer актуальна документация 0.5, а серия статей zag2art (начиная с этой) покроет значительную часть документации для Derby 0.6.
- участие в конференциях: Джозеф был на ForwardJS (к сожалению не нашел видео). Изначально должен был идти Нэйт и рассказать про тонкости и проблемы Agnostic Rendering (шаблонизатор, работающий и на клиенте и на сервере), но почему-то не смог, надеюсь еще услышим этот доклад. Ян был на JS встрече в Сан-Франциско.
Github
Derby переехал в новую группу. Это связанно с тем, что в старой накопилось много хлама и название Codeparty не отображало суть.
Активная часть сообщества создала свою группу, где потихоньку пилятся модули.
Lever тоже выкладывает свои наработки. Еще стоит обратить внимание на наработки компании Decision Mapper.
Сообщество
Сообщество медленно, но верно прибывает. Часто путь выглядит так: клиентский фреймворк (AngularJS, Ember и тп) -> Meteor -> Derby. Метеор хорошо помогает проникнуться концепциями realtime, full-stack, бд на клиенте, изоморфность и тп, но не удовлетворяет всех в силу тех или иных причин. Вообще, вот тут Нэйт очень интересно рассказал про основные фреймворки.
Недавно создали чат на Gitter.
Идеи
Есть несколько мыслей, по поводу того, что можно добавить или изменить в Derby:
Использование FoundationDB в качестве хранилища.
В текущей реализации livedb события на изменение документов ловятся за счёт Redis pub-sub (для одного node процесса, можно без Redis). И это часть функциональности является встроенной. Для хранения лога операций (oplog) и текущих версий документов (snapshots) используется внешний драйвер, который можно написать, в общем, для любой бд, например, для Mongo.
Проблемы в текущей реализации:
— использование двух бд, вместо одной.
— использование последовательного выполнения однопоточных Lua-скриптов в качестве альтернативы транзакциям, приводит к тому, что Redis потенциально становится узким местом (хотя пока никто с этим не столкнулся). Так же теоретически, при высокой коллаборации (много клиентов, обслуживающиеся разными node процессами, изменяют один документ) Redis'у потребуется значительно больше, чем одна попытка применить операцию к данным, так как текущая версия данных будет меняться от операциий других node процессов, что может повлиять на производительность (тут тоже проблем ни у кого пока не было).
— для случаев, когда клиент подписан на отсортированный запрос к коллекции (Query), нету возможности дешево понять как изменение очередного документа повлияет на его положение в данной query. В данный момент это делается довольно топорным способом: запрос применяется к коллекции, достаются все документы для этого запроса, высчитывается разница и отправляется на клиент (для приложений с большим количеством таких запросов это вызывает проблемы с производительностью). В данном случае проблема могла бы быть решена с помощью событий на изменение индекса в бд. К сожалению, бд с событиями на изменение индекса нет (если знаете, поделитесь). Наверно это не так трудно добавить в большинство бд, но никогда не было нужды (как вариант, можно попросить добавить это в Монгу).
FoundationDB имеет Pub-Sub и может заменить и Redis, и Mongo. Наличие встроенных транзакций упростит логику применение операций.
Также поверх FoundationDB можно написать свой Document Model слой, например fowl, в котором реализовать события на изменения индексов. Такой адаптер решит проблему отсортированных query.
Минусы FoundationDB — закрытость исходников, не бесплатность.
Джозеф уже наваял livedb-foundation. Дело за адаптером.
Клиентский кэш
Идея Offline веб-приложений подразумевает, что клиент хранит у себя данные, загруженные с сервера, даже когда приложение не запущено. И использует этот кэш, если нет возможности соединиться с сервером. Также клиент хранит изменения данных и при соединении с сервером синхронизирует данные в клиентском кэше с данными в бд, при этом конфликтные ситуации разрешаются. В идеале, пользователь должен иметь возможность открыть приложение без соединения с интернетом, поработать в нем, закрыть его и быть уверенным, что когда он в следующий раз откроет приложение и будет доступ к интернету, все результаты его работы попадут на сервер.
Derby/ShareJS представляется хорошей платформой для этого. Всё что нужно синхронизировать данные в модели с IndexedDB, научить Derby сначала искать данные в клиентском кэше, а потом (если доступен сервер) запрашивать с него разницу (новые версии). Также нужно при офлайне хранить операции в IndexedDB, и отправлять их на сервер при появлении соединения.
Access-control
Первый модуль access-control — racer-access имеет уязвимости с доступом по queries и в данный момент не рекомендован к использованию. В данный момент рекомендуется осуществлять контроль доступа на уровне ShareJS вручную или с помощью модуля share-access.
Есть идея совместить модуль валидации и access-control, добавив в схемы racer-schema подобие Firebase Security.
Послесловие
Всем, у кого есть вопросы по Derby/Racer/ShareJS, пишите мне на скайп vmakhaev.
Не пропустите Open Hours меньше, чем через час. Удачи!
