Шалость удалась (часть 4)
А зачем мне здесь PostgreSQL?
Первая версия backend появилась ещё до настоящего устройства, и проектировалась она с некоторым запасом. Несколько устройств, регистрация, heartbeat, хранение состояния — всё это довольно естественно привело к PostgreSQL. На VPS первоначальная схема выглядела примерно так:
Go Backend ───► PostgreSQL
И технически с ней всё было нормально. Но в какой-то момент я посмотрел на получившуюся систему и задал себе вопрос: а зачем мне здесь PostgreSQL?
У меня одна ESP32. Один backend. Один небольшой VPS. Устройство периодически отправляет крошечный heartbeat. Нет сложной аналитики, тяжёлых запросов, десятков пользователей или необходимости запускать несколько экземпляров приложения.
И ради этого рядом работает отдельный контейнер PostgreSQL. Конечно, можно было оставить всё как есть. PostgreSQL прекрасно справлялся с задачей. Но «справляется» ещё не означает «нужен».
Когда инфраструктура становится лишней На старте я закладывал возможность подключить несколько устройств и развивать мониторинг. Это не было ошибкой: тогда я ещё не знал, во что вырастет эксперимент. Но когда появился работающий прототип, стало ясно, какие требования действительно существуют, а какие пока живут только в моей голове. Если однажды понадобится собирать миллионы измерений, строить аналитику или масштабировать приложение горизонтально, архитектуру можно будет пересмотреть.
А сейчас отдельный сервер базы данных означал дополнительные настройки, контейнер, обслуживание и ещё одну сущность, о которой нужно помнить. Поэтому PostgreSQL я заменил на SQLite.
SQLite - не игрушечная база данных. Это полноценная транзакционная СУБД, просто встроенная в приложение и работающая с файлом вместо отдельного сервера. И для моего сценария она подходила прекрасно.
В результате вместо двух сервисов остался один контейнер backend и постоянное хранилище для файла базы данных. Меньше инфраструктуры - меньше вещей, которые могут потребовать внимания.
А frontend точно нужен? Похожий вопрос возник и с пользовательским интерфейсом. Можно было поднять React или Vue, организовать сборку, отдельный frontend -контейнер и deployment pipeline. Но зачем?
Мне нужна была одна страница: открыть браузер и увидеть, когда устройство последний раз выходило на связь, доступно ли оно сейчас и были ли сбои. Поэтому я оставил обычные HTML, CSS и JavaScript. Их раздаёт тот же Go backend, который обслуживает API. Никакого отдельного frontend - сервиса. Никакой сложной сборки. Один процесс, одна точка развёртывания.
Это не значит, что React или PostgreSQL плохие технологии. Просто каждая технология должна решать конкретную задачу, а не появляться в проекте исключительно потому, что я умею с ней работать.
Сначала работающая система Идей для развития хватало: графики доступности, SLA, история событий, метрики, уведомления, новые устройства. Но список улучшений у разработчика обычно заканчивается значительно позже, чем свободное время.
Поэтому я решил остановиться и зафиксировать главное: ESP32 стоит в офисе, выходит в интернет и сообщает о своём состоянии внешнему серверу. Если для этого достаточно Go backend и SQLite, значит именно столько инфраструктуры проекту сейчас и нужно.
Меньше строить архитектуру на вырост. Больше решать реальную задачу.
Правда, вскоре выяснилось, что даже самая простая архитектура не спасает от проблем, которые начинаются за пределами приложения. Но это уже следующая история.
