Первый рукописный блог рунета™

Внезапно вчера в Архангельске прошла мегаконференция StartupStandup и, хоть меня туда и не приглашали (какой из меня стартапер, ога), один сделанный нами проект там внезапно оказался.

Паче чаяния, проект по итогам голосования был признан лучшим и даже заказчику приз какой-то дали от Ростелекома.

Коль скоро заказчик проекта его официально презентовал, правда, больше с бизнесовой стороны, не вижу причин не расказать о solovki.pro с колокольни разработчика. Несмотря на то, что всё только-только из-под Under construction выведено, за некоторые вещи “уже не стыдно” (с).

Фронтэнд

С точки зрения посетителя – это калькулятор туров на Соловки. Кулькулятор сразу туры продаёт, а не только считает. Заказ или уже можно оформить, или вот-вот можно будет, ждём от Сбера подтверждение включения платежного шлюза.

Туры кастомизированы – то-есть выбирается транспорт, проживание и развлечения на месте. Калькулятор устроен таким образом, что знает capacity каждого ресурса на каждую дату и даёт заказывать соразмерно возможностям принимающей стороны.

В самом деле это агрегатор, то-есть фактически услуги оказывают разные компании. Агрегатор аккумулирует данные о номенклатуре услуг и их загруженности и отображает это всё пользователю в виде калькулятора.

Capacity, к слову, считается на сервере одним единственным хитрым map/reduce-ом всего на 200- SLOC.

Калькулятор – jQuery.my приложение, 120 с небольшим кб в исходных текстах. Сделан в CloudWall, там же и отлажен. На картинке вот калькулятор исполняется в отладчике, в окошке.

Приложение сложное, потому что надо учитывать кучу сценариев и пограничных случаев – и у меня нет уверенности, что мы учли их все, хотя старались.

Самый простой пример – доступность номерного фонда отеля не на конкретную дату, а в диапазоне (надо брать наименьшие значения по набору, с нюансами). Посложнее: что делать при сдвижке дат – можно лучше сделать, чем сейчас, и тп.

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

Мобильную версию калькулятора пока не делали – заказчик посчитал, что подождёт.

Приложения бэкэнда

Пользователь, рулящий данными в системе видит набор тех или иных, в зависимости от роли, веб-приложений, позволяющих управлять своей частью кухни.

Веб-приложения бэкэнда с самого начала заточены под работу в сетях с ненадёжной и медленной связью, то-есть они offline-ready. Однажды загруженная вкладка с приложением прекрасно работает и без соединения и заказчивает/скачивает изменения в данных, когда оно появляется. С учётом качества связи в местах экологического туризма это не прихоть.

Когда соединение есть хотя бы плохонькое, в основном приложении данные обновляются моментально, есчо.

В самом деле приложения даже не знают, с каким набором данных они работают – всю синхронизацию за них делает платформа. Приложение просто делает this.db.get(), this.db.query() или this.db.put().

Например, вот так выглядит диспетчер со старыми тестовыми данными:

Окошки таскабельны, компоновка сделана под большие мониторы – чтобы можно было свободное поле вокруг календаря обвесить окошками. На мониторах поменьше и планшетах, правда, тоже нормально, просто не 7 дней помещается по ширине.

Из диспетчера можно отправлять СМСки и звонить – это важно, потому что климат на Соловках переменчивый и иногда надо туристов оперативно уведомлять.

Естессно, все приложения – манифесты jQuery.my.

Технологии

Особо детально не буду расписывать, потому что есть чувствительные данные в системе.

Серверная часть – node.js, патченная CouchDB и nginx. То-есть, основная часть кода на JS и немножко на Erlang-е. База крутится на SSD. Памяти на инстанс надо немного совсем. В общем, ничего необычного.

На админском бэкэнде смонтирован локальный CloudWall, который содержит все исходники и почти все средства разработки. CloudWall также обеспечивает эмуляцию рантайма клиентского бэкэнда – все пользовательские приложения запускаются с нативными данными прямо в IDE.

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

Локальные данные позволяют трюки, которые затруднительны при обычной архитектуре – например, массивные map/reduce запросы. Вообще, серверные мощности бэкэнда очень скромны, потому что основной объём всякой тяжести вынесен в клиентские браузеры.

“Цена” поддержания канала постоянной синхронизации неожиданно невелика – примерно 14Кб в час, если новых данных не поступает/отправляется. Канал, кстати, гарантирует доставку в конечном итоге, сообщения не могут быть потеряны.

На фронтэнде, на заглавной в калькуляторе, конечно никакой живой синхронизации нет, это было бы избыточно.

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

Поглядим, как это всё полетит )

UPD. Хехе, тут вот уже багов накидали. Аккурат на пограничные случаи. Поправили, но чует моё сердце, что это не последние.

C целью “потрогать” arrow-функции в ES6 написал вот парсер выражений в польской нотации, простенький. Работает в консоли FireFox или в io.js, больше нигде не работает.

var polish = (function () {
  var ops = "+-/*".split("").reduce((a,b)=>(a[b]=Function("x","return x[0]=x.shift()"+b+"x[0],x"),a),{});
  return (s)=>s.split(/\s+/).reduce((a,b)=>(ops[b]?ops[b](a):!isNaN(b)&&b!=''?(a.unshift(+b),a):a),[]);
})();

polish ("10 1 2 3 + + *") напишет [60].

Пожалуй, я уже хочу стрелки в js. До этого как-то они мне не родными для js казались – ну и зря.

Полгода назад morfizm написал хороший пост про то, как работают технологии map/reduce для распараллеливания обработки больших объёмов данных.

Мне есть что к той истории добавить – все системы, что я построил за последний год, используют map/reduce для сортированной/группированной выборки данных из NoSQL БД. В силу целого ряда вкусностей мы используем CouchDB и примеры будут ближе к ней, но в остальных NoSQL БД принцип примерно такой же.

С помощью применения map/reduce практически любая сложная выборка по набору JSON-документов (деревья, не таблица) успешно приводится к простой выборке (цепочке выборок) диапазона ключей. В общем, для этого достаточно только map, про reduce я в следующий раз напишу.

Работает это так.

Пусть у нас есть БД с постами и комментами, то-есть с набором документов примерно такой структуры:

{type:"post", _id:"", author:"", title:"", stamp:0, content""}
{type:"comment", parentId:"", _id:"", author:"", title:"", stamp:0, content""}

Например, мы хотим выбирать сразу посты и комменты к ним за диапазон дат. Для такой выборки достаточно одной map-функции.

function Feed (doc) {
  if (doc.type==="post") {
    emit ([doc.id, 0], doc    );
    emit ( doc.stamp , doc._id);
    //       _↑_        __↑__
    //       key        value
  }
  if (doc.type==="comment") emit ([doc.parentId, 1], doc)
}

Наша map-функция, в зависимости от типа документа, эмитит пары ключ-значение. Для поста мы эмитим сразу две пары, а для коммента – одну.

Заметим, что разные комменты к одному конкретному посту эмитят себя по одинаковому ключу. Также заметим, что ключ может быть не только string, но и array.

Если пройтись этой функцией по нашей БД, мы на выходе получим набор пар ключ-значение со следующими свойствами:

1. Выбор из этого набора диапазона ключей startStamp … endStamp даст на выходе айдишники постов в этом диапазоне дат.


2. Выбор потом ключей вида
   [postId1, 0], [postId1, 1], [postId2, 0], [postId2, 1], [postId3, 0], [postId3, 1]…
   отдаст нам сразу и посты, и все комменты к ним.

Составной ключ я тут привёл отчасти для иллюстрации, чтобы показать, что с их помощью можно вносить дополнительное упорядочивание – посты и комменты в выдаче идут друг за другом.

Важный момент. Наша map-функция устроена так, что её результаты можно кэшировать и обновлять кэш не фуллсканом, а по частям, только когда обновился конкретный документ. Вычисление map-функций над набором доков прекрасно параллелится.

CouchDB именно так и делает. Над каждой базой можно создать набор именованных индексов, в которых хранятся результаты вычисления различных предопределённых map-функций. Выбирать из БД можно как по ID документов, так и по ключам результатов работы этих функций.

Индексы хранятся как B-tree, соответственно с рождения заточены под выбор диапазонов.

Чуток усложнив ключи с таймстампом – скажем, до [doc.author, doc.stamp], мы сможем выбирать посты конкретного автора. Диапазоны выборки ключей для первого запроса будут выглядеть тогда примерно так:  ["ermouth", 1420000000000] … ["ermouth", 1420014425025].

К такой схеме выборки после SQL пришлось некоторое время привыкать – но когда к ней приспособишься, оказывается, что она куда богаче SQL по возможностям одного только map.

На этой прекрасной ноте заканчиваю 2014 год.

Всем счастья, радости и приятных ништячков в 2015! Ушёл готовить оливье.