Intervals. Легковесный сервис для подготовки дашбордов

Приветствую, меня зовут Вячеслав. Занимаюсь разработкой и проект-менеджментом своих стартапов, пет-проектов и клиентских продуктов (в основном веб-приложения и различные внутренние проекты для медцентров). Что-то делаю соло, что-то в команде. Плюс продолжаю поддерживать свое агентство в РФ путем разработки различных проектов для его работы.

Так, для закрытия потребностей клиентов и с целью реализации интересной идеи весной 22 года написал сервис для построения быстрых дашбордов INTERVALS.RU.

Intervals. Легковесный сервис для подготовки дашбордов

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

Если кратко о механиках 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). Сервис доступен по ссылке.

22
Начать дискуссию