FlutterFlowとSupabase

この記事について

FlutterFlow（以降、FF）はノーコード／ローコードプラットフォームの1つで、そのデータ格納先としてFirestoreまたはSupabaseとの統合をサポートしています。
一つのアプリ内で両方のDBを使うすることも出来ます。
この記事では、Supabaseという選択肢について見解を記します。

Supabaseとは

一言で言えば、FirestoreのRDB版。
PostgREST等のオープンソースを統合してサービスを作り上げているのが特徴。
比較的新しいサービス。
シンガポールの会社。シンガポールは親中で、（CEOは違うように見えますが）華人・華僑の多い国。

FlutterFlowでのSupabaseサポート状況

FFは主にFirebaseを主軸に製品設計されています。Firebaseと組み合わせたときに出来ることが、Supabaseでは出来ないことが多々あります。FFとしては、RDBを使いたいユーザ層にリーチするためにSupabaseのサポートを入れたものの、そのデータモデルの違いをサポートできる体力（または意思）が無いのがリアルな状況だと勘ぐっています。

DB選定をミスると大掛かりな改修になるため、Supabaseで問題ないか、入念に事前調査されることをオススメします。Supabaseで不足している機能のサポート要求は、公式コミュニティのWishListに多く上がっています。「Supabase」で検索してみてください。（＊FFアカウントでログインしていないと見れないようです）

公式ガイドも確認し、Supabaseのデータを使って行いたい機能が紹介されているかも確認なさってください。ガイドは、大抵Firestoreとの組み合わせを例に記述されています。たちの悪い事に、「これはSupabaseで出来ません」と明記されていないこともたまにあり、アプリ構築途中に発見することもあります。例えば、地図画面でのマーカー詳細表示がFirestoreを使って紹介されていますが、Supabaseでは出来ず、出来ないとも書かれていません。開発途中にそういった事が見つかった場合、「その機能を諦める」「UI/UXを変える」という選択肢があれば良いですが、無理であればFFのサポートを諦めて独自のCustomWidgetとして作り込むか、DBを変えなければなりません。

今後の見通し

今後、Supabaseのサポートが拡充される見込みがあるかと言えば、現状ドキュメントモデルであればデータと画面での取り扱いをうまく行えているところ、RDBとドキュメントモデルでは概念的に異なる設計が多く、それらを上手く吸収してくれるかというと、かなり厳しいのではないか、というのが何となくの直感です。前述のWishListではかなりの要望（苦言）が出されているので、上手く吸収出来る分は対応が進むと期待できますが、同等の機能サポートは到底無理だと思います。昔、RDBとオブジェクト志向におけるインピーダンスミスマッチのような話があったのも思い出しちゃいました。

Supabaseと検索サーバ

サーバはDBだけですか？
検索サーバを入れる予定であれば、それらとの親和性も確認しておいた方が良いです。
Supabaseは比較的新しいサービスなので、サポートも限定的です。
例えば、Supabaseとの製品レベルでの統合機能が用意されておらず、PostgreSQLとのDBレベルでの統合機能を使わざるを得ない具合です。

検索サーバはAlgolia、Elastic CloudとMeilisearchを試したので、別途記事予定です。

ちなみにSupabase自身は、検索サーバという存在に否定的な立場というのが、記事から見え隠れします。とすれば、検索サーバ製品群との製品レイヤでの統合というのは、今後もあまり期待は出来なそう。

結論

FFの王道はFirestoreとの組み合わせです。脇道にそれると、そこは茨の道かもしれません。Supabaseで行くなら、入念に検証することを推奨します。

以下の条件が満たされているのであれば、Supabaseとの組み合わせも検討して良いと思います。

• アプリのライフタイムにおいてSupabaseの存続を確信している
• アプリのデータモデルとしてRDBが適している
• そのデータを用いて行いたい機能／将来的に想定される機能がFFで上手く出来ることが確認出来ている

アプリ；情報システム、とは、つまるところ情報を登録して、加工、整理、出力するためのもの。その中核となるDBが揺らぐと、待っているのは大改修です。ぜひ時間をかけてご検討ください。あなたが最短でゴール出来ることを願っています。