Я ненавижу руками создавать бойлерплейты. Любые. Нет, LLM-ки тут тоже не помогут: им надо писать промпты (а потом ещё проверять, что оно там нагенерировало). Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.

Именно в такой парадигме написана моя библиотека finitomata, в которой конфигурация конечных автоматов задаётся текстовым представлением (PlantUML/Mermaid), а бизнес-логика просто распихивается по колбэкам переходов. Но мне этого оказалось мало, и я решил обернуть в такие же абстракции хранение и подписку на изменения.

Так родилась библиотека (пока не опубликована, доступна только в исходниках) persistomata.

Я последовательно шёл к этой реализации, поэтому сначала были созданы Rambla для «публикации» в сторонние источники (текст на хабре) и Antenna для умного пабсаба (текст на хабре). Еще у меня завалялась библиотека Telemetría (текст на хабре), которая, вообще-то изначально писалась для упрощения работы с телеметрией, но потом обзавелась пользовательскими плагинами и теперь прекрасно подходит в качестве просто реализации аспектов для эликсира.

Картина с высоты орлиного полёта выглядит так (см. КДПВ):

• все отслеживаемые сущности являются конечными автоматами (это не страшно, в вырожденном случае он может содержать один переход в то же самое состояние с разными пейлоадами, что эмулирует «просто набор функций»);

• все переходы между состояниями обёрнуты в аспекты, отсылающие асинхронные сообщения в эфир; на эти сообщения можно подписаться из бизнес-логики (спасибо библиотеке antenna — очень гранулярно, если нужно), и на некоторые — подписано ядро persistomata;

• внутренние подписки публикуют полученные данные в настроенные «каналы» (спасибо rambla, каналы можно настроить какие угодно — от логов и пресловутой телеметрии, до базы данных) — по умолчанию это Clickhouse.

Таким образом мы просто шлём сообщения нашим конечным автоматам, инициируя переходы, которые отсылают сообщения во внешний эфир и пишут event log в clickhouse.

Из коробки предоставляется (пока одна) mix task, которая сгенерирует саму стейт-машину, тест для неё, и миграции для кликхауза. Миграций будет три, потому что помимо собственно ивентлога, мне потребуется нормальная таблица, которая реализована как materialized view на последних виденных состояниях «объектов».

Если помимо кликхауза — хочется прикрутить Postgres — добавьте свой listener средствами Antenna и пишите оттуда в базу. Нужен обмен горячими данными с братским микросервисом — добавьте RabbitMQ в конфигурацию Rambla. И так далее.

Оно по умолчанию прозрачно работает в кластере (горизонтальное масштабирование из коробки), легко дружится с Phoenix (в качестве примера я скоро допишу на этом движке хаброподобный форум, без модераторов и кармы — это чистый вайбкодинг, кстати, там только архитектура требует работы разработчика, со всем остальном справляются генераторы) и требует буквально нулевые ресурсы на взлёте. На моём ноуте (в контейнере с 8G RAM) бенчмарки показывают 80% загрузки на примерно 1000/50000 запросах в секунду (цифры write/read).

Поскольку я сейчас занят реализацией примера использования, очень интересны вопросы, комментарии и предложения. Всё-таки «хабрафорум» — это востребованный пример, но не совсем то, ради чего я затевался. Я метил преимущественно в микросервисы.

Удачного вайбкодинга!