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

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

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

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

Это классический вариант системы для работы с отчетами, где единожды проектируется структура отчетов и настраиваются графики под обновляемые данные:

Из крутых сервисов в этой сфере я бы выделил Datafan, Tableau, Geckoboard. Также можно вспомнить PowerBI и Google Data Studio (теперь - Looker Studio). Но все это про миллион интеграций, возможность постобработки данных на стороне сервиса и разные избыточные вещи.

Это все звучит хорошо, но говоря про тот же Data Studio — оно работает медленно (иногда — на грани полного зависания отчета), и если использовать ту же студию только в рамках подготовки отчетов с уже готовыми данными, то будет использоваться только процент от задуманного.

Также та же Looker Studio имеет особенности, мешающие комфортной работе (например, при смене порядка столбцов при выгрузке ломается настроенный репорт + нередко без повода сервис может “жонглировать” типом передаваемых данных, что также приводит к поломкам).

При довольно высоком уровне автоматизации отчетов, я часто занимался тем, что чинил подобные поломки на стороне сервиса, что тратит время без пользы.

Так что были причины писать узконаправленное решение с основным прицелом:

За визуальную основу графиков я взял 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 в первую очередь сделан для оптимизации части текущей работы, но если у кого-то возникают близкие задачи, связанные с визуализацией данных — буду рад тестам.

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

Ну и превращать это дело в самостоятельный коммерческий стартап не планирую, т.к:

В общем, буду рад тестам и с кем-нибудь пообщаться про Mongo). Сервис доступен по ссылке.