Intervals. Легковесный сервис для подготовки дашбордов
Приветствую, меня зовут Вячеслав. Занимаюсь разработкой и проект-менеджментом своих стартапов, пет-проектов и клиентских продуктов (в основном веб-приложения и различные внутренние проекты для медцентров). Что-то делаю соло, что-то в команде. Плюс продолжаю поддерживать свое агентство в РФ путем разработки различных проектов для его работы.
Так, для закрытия потребностей клиентов и с целью реализации интересной идеи весной 22 года написал сервис для построения быстрых дашбордов INTERVALS.RU.
Это решило проблему с подготовкой отчетов, унифицировало уйму процессов, избавило от тяжеловесных решений. Несмотря на то, что сервис не планировался и не планируется коммерческим, в пересчете на сэкономленные человека-часы он хорошо себя окупил.
Если кратко о механиках INTERVALS
Это классический вариант системы для работы с отчетами, где единожды проектируется структура отчетов и настраиваются графики под обновляемые данные:
- пользователь загружает данные из CSV-документов, XSLX-документов, через API (с передачей данных в формате, идентичном CSV с разделителем ; и кодировкой UTF-8);
- на основе данных пользователь можно создать графики с единичными, или скомпонованными данными в форматах линий, столбцов и прочих фигур, создавать виджеты, которые могут отражать динамику эталонного и сравниваемого периода, или другого измерения, или делать таблицы с тепловой картой;
- полученные элементы пользователь может объединять в дашборды;
- к основным элементам дашборда пользователь может давать дополнительные описания, а самими дашбордами может делиться с другими пользователями;
- при обновлении данных графики и виджеты обновляются автоматически и без поломок при сохранении тех же названий столбцов.
Из крутых сервисов в этой сфере я бы выделил Datafan, Tableau, Geckoboard. Также можно вспомнить PowerBI и Google Data Studio (теперь - Looker Studio). Но все это про миллион интеграций, возможность постобработки данных на стороне сервиса и разные избыточные вещи.
Это все звучит хорошо, но говоря про тот же Data Studio — оно работает медленно (иногда — на грани полного зависания отчета), и если использовать ту же студию только в рамках подготовки отчетов с уже готовыми данными, то будет использоваться только процент от задуманного.
Также та же Looker Studio имеет особенности, мешающие комфортной работе (например, при смене порядка столбцов при выгрузке ломается настроенный репорт + нередко без повода сервис может “жонглировать” типом передаваемых данных, что также приводит к поломкам).
При довольно высоком уровне автоматизации отчетов, я часто занимался тем, что чинил подобные поломки на стороне сервиса, что тратит время без пользы.
Так что были причины писать узконаправленное решение с основным прицелом:
- на выгрузку отчетов через API,
- с функционалом под визуализацию уже сгруппированных, отсортированных и по-прочим критериям нормализованных данных,
- с линейной структурой отображения графиков и прочей информации, чтобы читать отчеты было комфортно, внутри отчетов можно было бы показывать понятные клиенту исследования, прогнозы, рекомендации, а сама реализация новых репортов занимала минимум времени.
Первая реализация
За визуальную основу графиков я взял ChartJS. Библиотека имеет свои странности, но в целом это крутой инструмент.
В первой версии сервиса для экономии времени я написал фронтенд и клиентскую бизнес-логику максимально близко к бэкенду (Django) с темплейтами внутри приложения, скриптами в статике и прочим олдскулом. Все это было очень комфортно в реализации на тот момент, потому что на фронтенде я не имел много опыта, и такой подход сэкономил мне время.
Но обратная сторона медали прошлой реализации также понятна:
- с архитектурой в перспективе могут случиться большие проблемы (все предусмотреть сложно плюс со временем меняется личное понимание многих вещей);
- как следствие — спустя какое-то время с системой становится некомфортно работать.
Плюсом, в первой реализации сервиса на стороне бэкенда я реализовал много бизнес-логики, которую в рамках механик сервиса правильнее было бы держать на фронте.
Также до кучи немного перемудрил в скриптах с тем же функционалом тепловых карт внутри таблиц с данными.
В общем, в первой версии продукта я не все сделал правильно. И все это требовало серьезного рефакторинга и переработки. Но так как сервис хорошо выполнял свои задачи, а времени на пет-проекты не оставалось вообще, оно продолжило жить в таком виде.
К апрелю этого года немного разгрузился, потребность заказчиков в INTERVALS не делась — смог в парт-тайме снова заняться сервисом.
Текущая реализация
Основная проблема проекта на тот момент — тех долг. Чем менее прозрачней система, тем сложнее исправлять возможные косяки, не говоря уже о каком-то развитии. Близкое расположение фронта к бэкенду тормозило в данном случае вообще все.
На этапе перепроектирования сервиса выделил детали, которые трогать дорого и в целом можно оставить, и определил части, которые лучше переписать с нуля.
По итогу от первой версии сервиса остались только некоторые модельки, база данных и факт использования библиотеки ChartJS. Фронт в проекте, конечно, реализовал отдельно с переносом основной нагрузки на клиентскую сторону.
Если подытоживать текущий стек:
Бэкенд: Django, DRF.
Плюс на текущий момент осталась MySQL. Отмечу, что база выбрана нелогично.. не хватает Postgre, т.к. в работе приложения есть потребность в хранении JSON. Либо как вариант, можно подключить Mongo второй базой для части задач — здесь буду рад пообщаться с кем-нибудь, кто хорошо знает Mongo, т.к. с ней ранее не особо работал.
Фронтенд: React, Redux. Сделан на тайпскрипте, во-многом соблюдена VSD-архитектура, которая в последнее время мне кажется наилучшим архитектурным паттерном для фронтенда.
Что на текущий момент
Основные моменты по обновлению сервиса я закончил. Но есть много идей, как по оптимизации технической части, так и по функционалу, но так как в параллели у меня идет работа с другими проектами (QuickSpeak.me, Lingobot.ru) и клиентскими сервисами (веб-приложения) некоторые вещи могут затянуться. Хотя баги и что-то критическое, конечно, правлю оперативно.
Планы по сервису
Перегружать INTERVALS не планирую, т.к. одна из причин его изначального создания — усталость от перегруженности Looker Studio. В основных планах — находить и закрывать проблемы и баги, по мере закрывать несостыковки UX.
Также из архитектурной части есть идеи насчет переноса части бэкенда в SQL-функции, чтобы сделать Django-часть сервиса еще тоньше.
А из функциональной части в планах:
- режим просмотра на весь экран;
- механика общих комментариев внутри отчетов;
- возможность рисовать на графиках (с этого хочется начать в перв.очередь) — клиентам нравится черкаться, ради этого они любят тратить бумагу на страницы отчетов).
Для кого все это сделано
Intervals в первую очередь сделан для оптимизации части текущей работы, но если у кого-то возникают близкие задачи, связанные с визуализацией данных — буду рад тестам.
Сервис бесплатный (на мой взгляд деньги есть смысл брать только за что-то совсем высоконагруженное, что потребует вложится в сервер посерьезнее, либо за разработку каких-либо скриптов для обработки данных и формирования репортов).
Ну и превращать это дело в самостоятельный коммерческий стартап не планирую, т.к:
- сервис изначально задуман для закрытия внутренних рабочих задач, с чем хорошо справляется;
- приоритеты сейчас больше в сторону развития себя как фуллстек-разработчика, т.к. не живу в России с 21 года, и сейчас больше нацелен на проекты не европейском рынке (свои сервисы, либо в перспективе какой-нибудь интересный фуллтайм).
В общем, буду рад тестам и с кем-нибудь пообщаться про Mongo). Сервис доступен по ссылке.