В бете нового Двиналэнда применено довольно много технологических решений, снижающих нагрузку на облака. Одна из стратегий, которая попутно даёт мгновенный отклик некоторых интерфейсов – обработка, рендер и поиск на клиенте.
Называется это у нас “словари” и работает это примерно так.
Источники данных
Существует крупная категория данных, которые обновляются в подборках не по частям (как, например, новости), а разом. Это, скажем, ежемесячные отчёты об исполнении бюджета, какие-то списки организаций или услуг, телефонные справочники.
В силу характера документооборота это практически всегда или экселевские файлы (иногда с имитацией иерархии), или SQL-выгрузки, или веб-сервисы. Так или иначе, это всегда таблицы. Чаще – эксель.
Типичные объёмы – от сотен до единиц тысяч строк в 5-15 колонок. Связность обеспечивается в момент приёма до уровня гиперссылочной целостности – куда надо подставляются пермалинки.
Хранение
Такие данные неразумно хранить в “разобранном” виде – проще их в момент поступления в систему конвертировать в жестко унифицированный формат и хранить единой записью. В силу того, что у нас вся система – javascript, эта запись, понятно дело, json. Вопрос, какой структуры.
Коль скоро мы собираемся искать на клиенте, нам эти данные надо туда передать. Также очевидно, что перед поиском их можно будет обработать. Стало быть, надо делать представление с минимальной избыточностью, хорошо пакуемое gzip-пером уровня выдачи на скоростных режимах (ритмичное, то-есть).
Данные у нас табличные, пусть и с псевдоиерархией, так что задача это лёгкая. Мы конвертим исходные данные в массивы массивов, запоминая названия колонок.
То-есть не [{name:"John", year:1980}, {name:"Ann", year:1990}],
а примерно {cols:["name","year"], data:[["John",1980],["Ann",1990]]}
Передача
Только в силу структуры экономия против по-объектного, и, тем более, против HTML-формата, получается многократная.
Раз оно получается короткое (100Кб словарь пакуется до 10-15Кб), хранится единым куском и не требует сборки, его можно и нужно инлайнить. И мы действительно до определённого порога инлайним эти данные прямо в страницы выдачи.
То-есть, когда страница догрузилась, данные не просто тоже загружены, они уже даже разобраны и проиндексированы. В силу того, что большинство даже мобильных систем нынче двухпроцессорные, рендер и индексирование разносятся браузером по разным потокам и для пользователя это незаметно.
Рендер
Рендерятся данные после рендера всей содержательной статики. За выдачу данных с вкусным интерактивом отвечают jquerymy-манифесты.
Причём к одним и тем же данным могут быть привязаны разные манифесты, а к одному манифесту – разные данные. Например, в материале о расходах бюджета http://new.dvinaland.ru/budget/-e0ut55ow вверху бюджет диаграммой, а внизу – таблицей. Это одни и те же данные. Сама страница весит 450Кб, и эти данные занимают большую часть её объёма. При передаче это всё сжимается до 65Кб, размер небольшой картинки.
Там чуть менее 3000 строк данных в 5 уровнях иерархии.
Гибкость
С точки зрения редактора это выглядит как “поставить в этом вот место виджет Таблица с поиском и привязать к ней вот эти данные”. Это всё в админке интерактивное, драг-н-дроп, можно выбрать оформление, ширины колонок, фильтры и тп.
В силу того, что чётко разделены и стандартизированы попадание в систему, хранение, выдача и обработка, любое звено можно менять, не трогая остальные. Также любое звено легко форкается в целях тестирования.
С точки зрения юзера это выглядит как мгновенный отклик итерфейсов – все данные уже на клиенте и проиндексированы. Скажем, если на странице http://new.dvinaland.ru/gov внизу в справочнике наколотить gmail, можно увидеть, сколько ещё деятелей юзают вражью почту ггг.
За последние полгода эта цифра уменьшилась кратно, но остались ещё несознательные.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
