Технічні помилки при управлінні 16 продуктами на Lovable та Supabase
Ми керуємо 16 продуктами в Inithouse. Для всіх них ми використовуємо Lovable та Supabase. Усім цим керує одна команда. Це звучить непогано, поки ви не стикаєтеся з 16 кастомними доменами, 16 проєктами Supabase та 16 наборами edge functions.
Ми припускалися помилок, які коштували нам часу. Ось п'ять найбільших технічних помилок та наші способи їх виправлення.
1. Невідповідність схем баз даних
Наші перші три продукти використовували різні назви таблиць для одних і тих самих даних. В одному проєкті для аналітики використовувалася таблиця page_views. В іншому — analytics_events. Через це було неможливо писати спільний код. Завдання, яке мало б зайняти один вечір, розтягнулося на два тижні.
Виправлення: Ми створили спільний шаблон міграцій. Кожен новий продукт отримує однакові базові таблиці для аналітики, дописів у блозі та auth. Ми оновили старі проєкти під цей стандарт протягом спокійних тижнів. Тепер додавання endpoint для моніторингу займає 20 хвилин замість цілого дня.
2. Проблеми з кастомними доменами
Lovable дозволяє підключати кастомні домени. Іноді деплой проходить успішно, але перевірка DNS завершується помилкою. URL для попереднього перегляду працює, але на живому домені відображається порожня сторінка. Ми втратили три дні трафіку, бо не перевірили робочий URL.
Виправлення: Ми використовуємо чек-лист після публікації. Ми відкриваємо кожен живий домен в режимі інкогніто, щоб перевірити його. Також ми додали перевірку доступності (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