こんにちは、株式会社Pentagon代表の山本です。ここ最近、フロントエンド開発はメンバーだけで対応できる体制が整ってきました。まだ一部バックエンドの開発・インフラ構築の業務が、代表である私に属人化しています。特にRailsを使う場合、RDSやRails特有の知識が必要になるため、私がロックオンされています。
強固な組織にするため、この業務を私から引き剥がす必要があります。そこで、FirebaseをはじめとするMBaaS（Mobile Backend as a Service）を採用することで、従来のバックエンド業務をフロントエンドに任せることができないかと考えています。
しかしながら、何でもかんでもFirebaseを使えばよいということではありません。Firebaseにも致命的なデメリットが存在するため、バックエンドに何を採用するかは慎重に選ぶ必要があります。
今回は、毎回、バックエンドをRails・Firebase・Supabaseのどの技術（フレームワーク？）にするか、悩んでいる人に向けて、わかりやすくメリット・デメリットを比較していきます。
この記事を読めば、迷うことなく技術選定ができるでしょう。ちなみに、今回Rails・Firebase・Supabaseそれぞれを比較した結果、当社ではSupabaseを積極的に採用することにします。
| Rails | Firebase | Supabase | |
|---|---|---|---|
| PUSH通知 | △ | ◯ | △ |
| SNS・SMS認証 | △ | ◎ | ◯ |
| 検索性能 | ◎ | X | ◎ |
| リアルタイム通信 | △ | ◎ | ◎ |
| データ集計 | ◎ | △ | ◎ |
| アナリティクス | △ | ◎ | △ |
| 管理画面の実装 | ◎ | △ | △ |
| APIドキュメント生成 | ◎ | △ | △ |
| 学習コスト | △ | ◯ | △ |
| 人的リソース | △ | ◎ | ◯ |
| 運用コスト | △ | ◎ | ◎ |
Rails vs Firebase vs Supabase選定ポイント
PUSH通知を実装する場合
RailsアプリケーションをAWSのEC2にデプロイするので、PUSH通知にはAWSのSNSを利用しています。実装は必要だが、PUSH通知を送信するタイミングを自由に操ることができます。
Firebaseには、PUSH通知を簡単に送る機能Firebase Cloud Messaging(FCM)があるので、Firebaseをバックエンドに採用する際は、PUSH通知に関しては特に問題ありません。
一方、Supabaseでは、現在FirebaseのようにPUSH通知を送る機能は存在しません。
Is there any way to send push notification using supabase? #3588 にて議論されていますが、
データベースの変更を検知した時に、Firebase Cloud Functionを呼び出すことでPUSH通知を送ることができます。
Railsでバックエンドを構築する時に、AWSのSNSを利用していましたが、FCMでも良いので、PUSH通知の実装に関しては、今後Firebaseに統一した方が良さそうです。
SNS・SMS認証を実装する場合
RailsにSNS認証のためのGemはあるものの、mBassに比べると開発コストがある程度発生してしまいます。SNS連携のことを考えると、mBassを採用した方がメリットが大きいでしょう。
ちなみに、SMS認証に関して、FirebaseとSupabaseを比較すると、FirebaseはFirebase内でSMS認証が完結するものの、SupabaseはTwillioなどの別のSaaSと連携する必要があります。
検索性能に関して考察
Firebaseでは複雑な検索はできません。RailsとSupabaseはRDSベースなので、SQLを書けば複雑な検索も上手く処理することができます。データの検索が重要となるアプリの開発において、軽い気持ちでFirebaseを使うと将来的にボトルネックになり得ます。そういったケースではRailsまたはSupabaseの利用が望ましいでしょう。
リアルタイム通信を行う場合
RailsはActionCableを使えばリアルタイム通信ができるが、サーバー構築のコストやクライアントサイドとの連携コストを考えると、あまり実装したくはありません。一方で、mBassでは特に難しいことをしなくてもリアルタイム通信を行うことができます。
データ集計をしたい場合
データの集計に関しては、RDSに軍配が上がります。Firebaseでは、COUNTやSUMなどの集約関数はサポートされていません。RDSであれば、SQLを書けば良いし、集計用のテーブルをDBに作成することも可能です。
アナリティクスに関して
Googleアナリティクスには勝てません。バックエンドをどの構成にするのかによらず、アクセス分析はGoogle Analyticsを利用させてもらうのが良いでしょう。
管理画面を開発する場合
管理画面の構築という観点では、Railsが優れています。Scaffoldを使えばコマンド一発でCRUDの画面を作成することができるからです。FirebaseやSupabaseを利用する際は、管理画面を自作する必要があります。
APIドキュメントの作成したい時
RailsであればSwaggerドキュメントを自動生成することができるため、APIドキュメントの作成コストを削減できます。一方、FirebaseやSupabaseを利用する場合は、APIドキュメントを手動で作成する必要があります。
そもそもAPIドキュメントは、フロントエンドエンジニアとバックエンドエンジニアとがコミュニケーションをとるためのツールです。FirebaseやSupabaseを利用すれば、フロントエンドとバックエンドの境界がなくなり、APIに関するコミュニケーションが少なくなるはずです。特段APIドキュメントを用意しなくても、アプリケーション側のソースコードにコメントを書き込むことによってドキュメント化しても良いでしょう。（お客様の要望でドキュメントを用意してほしいと言われた場合は別ですが。）
運用コストに関して
mBassのサービスを使った方が運用コストを抑えることができます。Firebase/Supabase側がサーバーの面倒を見てくれるので、気持ち的にも楽ですね。
学習コストに関して
フロントエンドエンジニアがゼロから学習する場合、Firebase > Supabase > Rails の順に優れています。
Firebaseはそもそもアプリエンジニアであれば使ったことがある人が多いですよね。Supabaseであれば、SQLやDB設計だけマスターすれば使うことができそうです。一方で、フロントエンドの人間がRailsを習得するのにはそれなりの時間がかかります。
人的リソースに関して
Railsでアプリ開発をする場合、Railsプロジェクトの人員とFlutterプロジェクトの人員とが必要となります。一方で、mBassを採用する場合、１つのチームで開発を行う傾向が強くなります。少人数で生産性を上げていくためには、mBassを利用した方が良いでしょう。
Rails・Firebase・Supabaseそれぞれのメリット・デメリット
Rails x RDSでバックエンドを構築する
Railsのメリット
scafoldを駆使して一瞬で管理画面を構築することが可能
swaggerを使うことでAPIドキュメントもほぼ自動的に作成可能
基本的に頑張れば大抵のことはできる
Railsのデメリット
Rails、AWSの知識が必要、学習コストがかかる
バックエンド担当者が必要
APIを手動で開発するコストが発生する
ActionCableを使えばリアルタイム通信できるけど、工数大
Firebaseでバックエンドを構築する
Firebaseを採用するメリット
- 高速に開発できる
- フロントエンド側でアプリ開発を進めることができる
- 学習コストが低い
- リアルタイム通信が簡単に実装可能
Firebaseを採用するデメリット
- 検索が雑魚。複雑な検索条件には耐えられない。
- Web管理画面は別途自作する必要がある
Supabaseでバックエンドを構築する
Supabaseを採用するメリット
- APIを開発する必要がなく高速に開発できる
- Firebaseのように検索性能で困ることがない
Supabaseを採用するデメリット
- Web管理画面は別途自作する必要がある
- PostgresやSQLの知識が必要。学習コストがかかる
- FirebaseのようなPUSH通知の機能は現在提供されていない
- まだまだ利用者が少なく不安が残る
まとめ
今回、こうしてRails・Firebase・Supabaseそれぞれを比較してみました。結果、Pentagonでは脱Railsを行いつつメインのバックエンド技術をSupabaseに移行した方が良いと考えています。ただし、PUSH通知とアナリティクスに関してはFirebaseを利用することで、Supabaseでカバーしきれない部分を補う必要があります。Web管理画面については、CRUDの画面を高速開発できるようなテンプレートを用意して、開発コストを削減することに努めていきます。
