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

Месяц назад мы запустили публичную бету vezdelegko.ru, сервиса бронирования экскурсий, отелей и транспорта. Сервисы бронирования – сами по себе штука сложная, это как магазин, по которому надо вести учёт ассортимента на каждый день, причём ассортимент день ото дня меняется и цены зависят от дня и количества. Причём в магазине куча отделов, и партнёры сами управляют своим ассортиментом.

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

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

Code follows data

Нативная CouchDB хранит в базах не только данные, но и код для predefined map/reduce запросов, по которым строятся высокоэффективные persistent индексы. Этот код, на JS или Erlang, хранится в документах рядом с данными и может распространятся между узлами в тех же потоках репликации, что и сами данные.

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

Особо примечателен факт, что с точки зрения установленного софта узлы не различаются вообще.

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

Файлы – это очень скучно

Важный момент, как именно код функций попадает в БД.

Код лямбд вообще не существует в виде исходных файлов. Он создаётся в специализированной среде разработки, основанной на CloudWall и Ddoc Lab. Выглядит это примерно так:

То-есть, сорцы, из которых собираются лямбды, хранятся в PouchDB в браузерах разработчиков, реплицируются в CouchDB на какой-то из узлов, собираются, а затем распространяются по остальным узлам.

Деплой обновлений и скорость разработки

Такая архитектура расслаивается на три части по критерию обслуживания:

1. Убунта, CouchDB, Redis, node.js и nginx – фундамент со временем между рестартами в месяцы. Для обновления или рестарта фундамента нужен доступ к каждому узлу через терминал.
2. Couchbox – платформа приложений с временем между обновлениями сейчас в недели, скоро станет в месяцы. Разрабатывается на файловой системе в обычных IDE, для обновления на узлах нужен доступ через терминал.
3. Код приложений, очень гибкий, может обновляться и дополняться с высокой частотой. Для разработки и отладки как клиентской (UI), так и серверной части (REST API) приложений не нужно ничего, кроме браузера. Код деплоится по узлам автоматом.

Общий объём кода, написанного в браузере для этой системы, перевалил за 100К SLOC и пока всё просто прекрасно. Стартскрин бэкэнда выглядит сейчас вот так:

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

И да, Couchbox is MIT licensed. Опенсорц наше всё.

Написал длиннющий пост про isomorphic apps – и у меня впервые за тыщу лет выпал LiveWriter, причем сразу с XP (да-да, я для LiveWriter-а спецом держу под Parallels-ом Windows XP, заодно там тёплый ламповый IE8 для тестов).

Наверное, это мне вселенная так говорит, что надо покороче написать пост )

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

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

Причин такого подхода две:

1. Для рендера документа в ~статический HTML нужно гораздо меньше кода, чем для редактирования этого-же документа. Стало быть, “серверная” версия приложения может быть проще и быстрее – например, нам незачем обрабатывать события, поэтому код может быть синхронным.
2. На бэкэнде (который offline ready) и в публичной части существенно различаются способы адресации бинари-ресурсов (картинки, документы для скачивания и тп). Картинки в режиме редактора, например, имеют уникальные каждый раз разные сессионные ObjectURL, а в публичной версии это простые всегда одинаковые пермалинки.

Overhead на такой подход в строках кода оказался неожиданно небольшой (~200SLOC для приложения в 300Кб JS) – но я вряд ли буду делать так часто.

Дело в том, что любой код, модифицирующий другой код, довольно hacky. Такой код требует тщательного обдумывания и аккуратного написания, и всё равно он от этого не становится “прозрачным”.

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

В общем, интересно, но не серебряная пуля.

Внезапно вчера в Архангельске прошла мегаконференция 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. Хехе, тут вот уже багов накидали. Аккурат на пограничные случаи. Поправили, но чует моё сердце, что это не последние.

Я вчера, уже когда засыпАл, пребывая под впечатление от Win95 на JS, размышлял, чего же не хватает, чтобы сделать из браузера условно-полноценную платформу для виртуализации. То-есть, сделать из браузера гипервизор.

В диктофон записалось “локалсторидж и юдипи”, после этого я уснул. Расшифровываю.

Синхронная файловая система

В браузерном JS есть всего две сущности, которые могут сойти за синхронную запись/чтение на файловую систему, и обе очень ограниченные.

localStorage – единственная локальная браузерная БД, чтение/запись в которую синхронные. Главная проблема – localStorage крошечный, единицы мегабайт.

Есть ещё IndexedDB и уже считающаяся устаревшей (а напрасно) WebSQL – они дают объём до 1/10 диска на домен, но они обе асинхронные.

Synchronous XHR – синхронный ajax-запрос. Это сетевой запрос, а не локальный, стало быть сразу прилагается куча соответствующих проблем. Более того, Mozilla пометила синхронные ajax-запросы как deprecated.

В этой связи я предполагаю, что либо лимит на localStorage будет увеличен, либо появится какой-то новый механизм (либо адаптация имеющегося).

Про “адаптацию имеющегося” я говорю вот почему. В браузерах накоплено существенное количество самых разных технологий, которые могут очень неожиданно сочетаться. Например, btoa(unescape(encodeURIComponent(string))) служит для конвертации в base64 unicode-строк, и лишь единицы самых рафинированных экспертов впервые её увидев скажут вам, как и почему это вообще работает. Хотя все три функции – “системные” для браузера, их сочетание вводит в полный ступор сначала.

UDP

Сейчас в браузере нет никакого способа выполнять UDP-запросы. Я не думаю, что он появится, потому что такая возможность ставит под угрозу безопасность не конечного пользователя, а всей сети. Тем не менее, очевидно существует множество “классических” приложений, которым нужен UDP. Как тут быть, не очень понятно.

В браузере есть некоторое "идейное” подобие, чтоли – называется WebRTC. Эта технология предназначено для веб-версий “настольных” технологий, где UDP задействуется особенно широко. Потоковое видео, VoIP и тп.

Возможно, WebRTC будет как-то адаптирован под более широкового плана нужды.

Итого

Френды, если есть у вас какие-то навскидку соображения про фундаментальные ограничения на идею “браузер как гипервизор” – напишите плиз коммент.

В субботу с утра пораньше сел писать доки к новой фиче в CouchDB. Это уже третий подход к снаряду – доки там в в волшебном формате .rst, который через жопу показывается буквально во всех IDE, что у меня установлены как нативные приложения, и даже это “через жопу” требует установки зависимостей пачками.

В результате я плюнул искать и напилил редактор этого .rst сам. Заняло это по часам 27 минут, из которых половину я потратил на поиски и вкручивание в приложение подходящего мода для кодмиррора и его зависимостей.

Это всё, естессно, не выходя из браузера, прямо в CloudWall. Теперь эти rst, которые руководства к CouchDB, наконец-то и хранятся в CouchDB, ога.

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

UPD. Ой, забыл код приложения же показать. Вот он:

Зарелизил CloudWall 1.8, в который вошло новое приложение – Ddoc Lab.

Для этого приложения, выведенного стэндэлоном, сделал отдельный сайтик. Сейчас инглиш вычитывается и пытаюсь пофиксить merchant-account на пэйпэле (дичайший гимор). А так всё уже работает в хорошем приближении.

Клик по картинке – на сайт.

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

Софтинка эта написана в полном CloudWall-е, а на сайте работает под его порезанной стэндэлон-версией. То-есть теперь у меня есть такая специальная версия CloudWall, которая поддерживает всего одно приложение и одну открытую БД на вкладку. И есть генератор этой мини-версии из большого CloudWall-а, да.

То-есть это позволяет релизить сингл пэкиджом из одного JSON-файла сразу и приложение, и ОС под ним. Этот JSON можно копипастить как документ в CouchDB – и приложение сразу взлетает на той базе, куда скопипащено.

Ещё заодно пробую “Pay what you want” модель монетизации – Ddoc Lab в виде JSON-а в некоторых случаях может быть просто бесценен ) То-есть это можно приложение поставить себе в CouchDB  в один копипэйст буквально – и заиметь человечий редактор индекс-функций и приложений у себя локально.

Такие дела.

Написал за ночь сегодня логгер для следующеего релиза CloudWall, сейчас потестил – оч шустро вышло. Написал заметочку в корпоративной Стене и решил сюда кросспостнуть.

Под катом инженерные соображения про логгер для браузерной системы.

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

Справочно: скорость записи в localStorage небольших фрагментов (десятки килобайт) колоссальна: на моём i7 – сотни мегабайт в секунду в любом браузере. Это многократно превосходит среднюю скорость сериализации в JSON, например.

Коллеги, что я забыл про важные фичи лога?

Мы все привыкли, что в javascript-коде, особенно клиентском, можно особо насчёт RAM не париться. Автоматические сборщики мусора уже очень хороши во всех браузерах и прекрасно переваривают даже существенно корявый код и сложно зацикленные указатели.

Но есть одно исключение, когда памятью в js нужно управлять прямо – то-есть делать allocate-deallocate кодом, а не полагаться на автомат. В полный рост это исключение проявляется в noBackend приложениях.

Жизнь без пермалинков

Дело в том, что для бинари-ресурсов, хранимых локально в браузере, не существует пермалинков. То-есть, если надо вставить картинку, то src="http://url.com/image.jpg" написать не получится – нет у картинок урла.

Год назад я запустил первую версию cloudwall.me. Жэжэшечка у меня тогда была закрыта, так что написал я об этом только в мае и в Medium.

В тот момент cloudwall.me работал на PouchDB 1.4 (это такая локальная NoSQL БД в браузере). Тогда она была дико глючная и медленная. За год PouchDB стараниями комьюнити доросла до 3.3 и стала вполне стабильной. Среда исполнения приложений на jquerymy за год тоже здорово подросла и в плане скорости, и в плане надёжности.

Плюс добавился IDE, плюс ещё всякие редакторы и приложения, плюс я сайт jquerymy переделал.

Короче, сейчас cloudwall.me – простейшая браузерная ОС, которая для работы не требует инет-соединения. Год назад я говорил (и думал), что ОС эта совсем игрушечная – но, похоже, что не такая уж и игрушечная.

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

И контракт этот – на разработку софта на платформе cloudwall.me. Offlline-ready, все дела. Интересно, что контракт сам меня нашёл.

Что дальше

CloudWall система уникальная в том плане, что её исходники не существуют в виде файлов.

Текущая версия CloudWall (платформы) создана внутри него самого, исходники – это JSON-документы в локальной браузерной БД. Синхронизированной, конечно, с удалёнными репликами CouchDB.

Сам сайт cloudwall.me – статически слинкованный – это один документ CouchDB с 32 аттачами. То-есть, чтобы запустить CloudWall у себя, как свой сайт, достаточно поставить CouchDB и скопировать в неё один-единственный документ. Больше ничего делать не надо – оно сразу заработает само.

В общем, я планирую довести это всё до стадии open-source для начала. Это не так и просто – потому что файлов нет, а на гитхаб можно положить только файлы, то-есть нужен трюк.

А дальше у меня есть соображения, откуда могут проявиться интересные деньги. Потому что если к этому прикрутить CoverCouch и сделать централизованные профили пользователей, получается распределённая ОС с безопасностью, пригодной для корпоративного сектора.

Что-то типа MS Active directory + DFS получается, только в браузере и для запуска js-приложений. Ну и без дикого сопутствующего гимора как в Винде. И клиенты по определению однопользовательские.

Но сначала я раскрою cloudwall. Скоро на гитхабе, да.

У меня тут в качестве побочного инструмента разработки возникла потребность в нормальном JSON-редакторе. Это то-есть такого, который:

• распознаёт таймстампы и показывает их как даты


• понимает стрингифаенные функции


• определяет, что строка – base64 и её можно показать/скачать


• прощает ошибки набора JSON (пропуск кавычек), но генерит корректный JSON


• понимает JS-выражения, которые сразу вычисляет


• позволяет размножать/переставлять ветки


• позволяет каждую ветку поправить сорцом


• даёт экстендить один JSON другим.

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

У меня такой редактор написался внезапно, и такой хорошенький, что я вот его обвесил всякими сэмпл-доками и выложил как online tool. Он умеет доки хранить в локалсторидже есчо, так что всё помнит.

http://cloudwall.me/etc/json-editor.html

Любопытно, что эта штука – “рекурсивное” приложение. Оно при раскрытии веток юзером инстанцирует само себя как дочки. Я сначала думал что это довольно дорого в плане памяти и CPU, но неожиданно оно норм даже на айпаде полетело. Хотя прожорливое, конечно.