Технические ошибки при управлении 16 продуктами на Lovable и Supabase
В Inithouse мы управляем 16 продуктами. Для всех них мы используем Lovable и Supabase. Всем этим занимается одна команда. Звучит неплохо, пока вы не столкнетесь с 16 кастомными доменами, 16 проектами Supabase и 16 наборами edge functions.
Мы совершали ошибки, которые стоили нам времени. Вот пять самых крупных технических ошибок и способы их решения.
1. Несогласованные схемы баз данных
В наших первых трех продуктах использовались разные названия таблиц для одних и тех же данных. В одном проекте для аналитики использовалась таблица page_views. В другом — analytics_events. Из-за этого было невозможно писать общий код. Задача, которая должна была занять один вечер, растянулась на две недели.
Решение: Мы создали общий шаблон миграций. Каждый новый продукт получает одинаковые базовые таблицы для аналитики, постов в блоге и авторизации. Мы доработали старые проекты в периоды затишья. Теперь добавление эндпоинта для мониторинга занимает 20 минут вместо целого дня.
2. Проблемы с кастомными доменами
Lovable позволяет подключать кастомные домены. Иногда деплой проходит успешно, но проверка DNS завершается ошибкой. Preview URL работает, но на основном домене отображается пустая страница. Мы потеряли три дня трафика, потому что не проверили live URL.
Решение: Мы используем чек-лист после публикации. Мы открываем каждый live домен в режиме инкогнито для проверки. Также мы добавили проверку аптайма (uptime check), которая отправляет уведомление в Slack, если домен недоступен.
3. Фрагментированная видимость данных
Мы не могли видеть показатели всего нашего портфеля, не открывая отдельные дашборды для каждого продукта. Мы работали вслепую.
Решение: Мы развернули stats API endpoint в каждом проекте Supabase. Каждый продукт отправляет ключевые метрики, такие как количество пользователей и регистраций, в стандартном формате. Один скрипт собирает эти данные в единый дашборд.
4. Копирование компонентов
Раньше мы копировали React-компоненты из одного проекта в другой. Эти компоненты несли в себе старые допущения. Карточка с ценами из одного продукта не работала в другом, потому что ожидала иной процесс оплаты. Мы тратили дни на отладку этих «фантомных» багов.
Решение: Мы перестали копипастить. Мы ведем документ с паттернами компонентов. Мы просим Lovable создать новый компонент на основе этих паттернов. Это дольше в настройке, но гораздо проще в поддержке.
5. Использование истории чата в качестве документации
Мы полагались на историю чата в Lovable, чтобы помнить технические решения. Логи чатов — это хаос. В них перемешиваются успешные изменения и неудачные попытки. Найти конкретную причину изменения в длинной ветке обсуждения очень сложно.
Решение: Мы перенесли логирование решений в Linear. Мы пишем одну строку в Linear, объясняющую, что именно изменилось и почему. Чат в Lovable предназначен для исполнения, а Linear — для принятия решений.
Урок прост. Не относитесь к 16 продуктам как к 16 отдельным проектам. Относитесь к ним как к единому портфелю. Стандартизируйте свои шаблоны и отслеживайте всё из одного места.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi