Паттерн-матчинг и забытые миры
Nov. 26th, 2015 08:03 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ermouthКажется, будет CouchDB 1.7 (тьфу-тьфу, падаем ниц, о великий @kxepal) и в ней мой JS-рерайт.
Мы сами этот JS-рерайт вовсю уже юзаем и сейчас клепаем с ним секретный вполне боевой проект. Прокси из нода с express.js перед CouchDB стал не нужен – проект умеренно нагруженный, так что Кучдбшный Spidermonkey в самый раз. Любопытно, что кода получается меньше, чем в ноде.
В силу того, что JS-рерайт это, по сути, раутер запросов, такая входная точка для доменного имени – мне понадобилась JS-библиотечка для паттерн-матчинга. Желательно, с близким к Эрлангу синтаксисом.
Ну то-есть разбирать запрос и перенаправлять его куда надо, меняя ключи там, проверяя авторизацию и прочее и прочее.
Библиотечка такая нашлась, но она оказалась “одноуровневая”. Я её маленько допилил, чтобы поддерживался рекурсивный синтаксис, как на картинке.
Выложил как гист, под гистом коммент с инструкцией. Кому надо – забирайте.
Ещё немножко о секретном проекте, скриншот справа как раз его кусочек.
У нас там впервые в полный рост offline-first, то-есть все веб приложения для авторизованных юзеров нормально работают без интернет-подключения.
Делаем всё для таких мест, где с покрытием и качеством сети всё хреново, поэтому вот так. По-хорошему, это всё CloudWall.
Забавно, что как раз именно такой подход и позволил использовать небыстрый внутренний Spidermonkey в CouchDB, а не шустрый node.js. Дело в том, что мы все вообще тяжёлые map/reduce queries и весь вообще рендер UI выполняем на клиенте.
То-есть мы и на сервере map/reduce можем исполнять – клиент использует тот же код – но паразитировать на вычислительных мощностях клиента и быстрее, и offline-ready, и сервер можно относительно слабый.
По сути, задача сервера – поддерживать на клиентах релевантный датасет и отдавать стартовый код приложений. Ну и, конечно, чувствительные данные живут только на сервере.
Ну понятно, что интерфейсы дикой красоты, responsiveness просто вау, на ойпадах летает ну и всё такое.
---
В процессе написания поста выяснил, что у меня в WinXP висит незакрытая Цивилизация. Интересно, сколько она там так втихую сидела в почти всегда спящей виртуальной машине – полгода? Год? Забытый мир, да ))
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-11-26 09:09 am (UTC)Как реагируете на коллизии? Например, соединение отсутствовало и в локальном хранилище есть конфликтующие изменения.
no subject
Date: 2015-11-26 09:23 am (UTC)На коллизии реагируем ручками, примерно как в дропбоксе. Если правильно роли разводить и схемы хранения, коллизии – чрезвычайная редкость.
Плюс у нас явное сохранение почти везде, надо кнопоку Save нажать. Если за это время открытый документ локально поменялся (издалека обновился), конфликт будет пользователь прямо при сохранении разрешать.
no subject
Date: 2015-11-26 11:07 am (UTC)Меня всегда волнуют такие ситуации (она редкая, но когда-нибудь да встретится):
1) Первый клиент не имел доступ в сеть. Он изменил документ и сохранил.
2) Второй клиент изменил этот же документ и он ушел на сервер.
3) Первый клиент изменил документ снова и сохранил.
4) У первого клиента появилось соединение и все его изменения пошли на сервер.
Будет два конфликта или будет неявный мердж документов из шагов 1 и 2?
no subject
Date: 2015-11-26 11:23 am (UTC)Тут важно а) что будет раздавать сервер новым клиентам (какая версия «выигрывает») и б) что окажется на конфликтующих нодах.
Если коротко, в результате главной версией (видимой по _id) станет последняя версия первого клиента. Тем не менее, на обоих клиентах и на сервере база сохранит все версии, а на клиентах ещё и просигналит, что в ней есть два форка и надо бы решить, что делать.
Автоматический мёрж не происходит никогда.