LovableとSupabaseで16のプロダクトを運用する際の技術的なミス
Inithouseでは16のプロダクトを運営しています。すべてにおいてLovableとSupabaseを使用しています。1つのチームですべてを管理しています。一見良さそうに聞こえますが、16個のカスタムドメイン、16個のSupabaseプロジェクト、そして16セットのEdge Functionsに直面すると話は変わってきます。
私たちは時間を浪費するようなミスを犯してきました。ここでは、最も大きかった5つの技術的なミスと、その解決策を紹介します。
- データベーススキーマの不一致
最初の3つのプロダクトでは、同じデータに対して異なるテーブル名を使用していました。あるプロジェクトでは分析用に page_views を使い、別のプロジェクトでは analytics_events を使っていました。これにより、共通コードを書くことが不可能になりました。本来なら午後だけで終わるはずのタスクに、2週間もかかってしまいました。
解決策：共通のマイグレーションテンプレートを作成しました。新しいプロダクトにはすべて、分析、ブログ投稿、認証用の同じベーステーブルが用意されます。既存のプロジェクトについては、業務が落ち着いている週に遡って修正を行いました。現在では、モニタリング用のエンドポイントの追加は、丸一日ではなく20分で完了します。
- カスタムドメインの不具合
Lovableではカスタムドメインを接続できます。しかし、デプロイは成功してもDNSの検証に失敗することがあります。プレビューURLは機能するのに、ライブドメインでは空白のページが表示されるといったケースです。ライブURLを確認していなかったために、3日分のトラフィックを失いました。
解決策：公開後のチェックリストを使用しています。すべてのライブドメインをシークレットウィンドウで開き、動作を確認します。また、ドメインがダウンした場合にSlackへ通知を送るアップタイムチェックも導入しました。
- 断片化されたデータの可視性
プロダクトごとに個別のダッシュボードを開かなければ、ポートフォリオ全体のパフォーマンスを確認することができませんでした。私たちは暗闇の中を飛んでいるような状態でした。
解決策：すべてのSupabaseプロジェクトに統計APIエンドポイントをデプロイしました。各プロダクトは、ユーザー数やサインアップ数などの主要なメトリクスを標準化された形式で送信します。単一のスクリプトがこれらのデータを収集し、1つのダッシュボードに集約します。
- コンポーネントのコピー＆ペースト
以前は、あるプロジェクトから別のプロジェクトへReactコンポーネントをコピーして使っていました。しかし、これらのコンポーネントには古い前提条件が含まれていました。あるプロダクトの料金カードが、別のプロダクトでは決済フローが異なるために動作しないといったことが起こりました。私たちは、こうした「幽霊バグ」のデバッグに何日も費やしました。
解決策：コピー＆ペーストをやめました。代わりにコンポーネントパターンのドキュメントを維持しています。Lovableに対して、これらのパターンに基づいて新しいコンポーネントを作成するよう指示します。セットアップには時間がかかりますが、メンテナンスは格段に容易になります。
- チャット履歴をドキュメントとして使用すること
技術的な決定事項を覚えておくために、Lovableのチャット履歴に頼っていました。しかし、チャットログは乱雑です。成功した変更と失敗した試行が混在しています。長いスレッドの中から、特定の変更が行われた理由を見つけ出すのは困難です。
解決策：決定事項の記録をLinearに移行しました。Linearに「何が、なぜ変わったのか」を1行書きます。Lovableのチャットは「実行」のため、Linearは「決定」のために使います。
教訓はシンプルです。16のプロダクトを16個の別々のプロジェクトとして扱わないでください。それらを1つのポートフォリオとして扱いましょう。テンプレートを標準化し、すべてを1か所から監視するようにしてください。
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi