Bubbleでは、BubbleのDBを使うケースと、外部のDBと連携するケースがあります。
それぞれどんな観点で決めた方が良いのかについて書いてみます。

BubbleのDBのメリット

• BubbleのDBを使った方がBubbleから扱いやすく開発が早い

• ツールが1つになるので管理が楽

• 外部DBの費用がかからない

管理が楽でスピードも早くて安いという並びになりました。
中間テーブルは作らずに、フィールドをlistにしてデータを複数保存させるケースがよくあります。Bubbleからはその方がすぐにデータが取り出せて楽なので、Bubbleから扱うことに特化したDBっぽいイメージです。

DBの定義の変更などもBubble内だと楽なので、基本路線はBubbleのDBを使うで良いと思います。

BubbleのDBのデメリット

必須にできない

BubbleのDBを使った場合には他サービスとの連携が手間

Bubble外部から直接DBを触れないため、外部のBIツールとの連携が直接できません。Redashとか Looker Studio ですね。
テーブル単位でAPIとして定義ができるため、このAPIを使うかzapierなどを使う必要があります。スプレッドシートに一度データを保存するなどして、それをBIツールと連携するイメージです。

もしくはダッシュボード系も全部Bubble内で自作をするという手もありますが、クエリ書くだけの方が楽ですよね。

作り変える想定があるのかどうか

Bubbleで作る場合には 大きく分けて2パターンあると思います。

1. 社内ツールや小さいツールなどで、作り替えずにBubbleを前提で考えている

2. MVPとして検証目的で作り、うまくいったら作り変える

Bubble前提の場合

メリットに書いた内容そのままなので、基本的にはBubbleのDBを使うで良いと思います。

MVPとして作る場合

PMFするまでBubbleでその先はプログラムを書くケースです。
観点としては

• PMFまでいかに早く持っていくか

• 作り変えるコストをいかに下げるか

あたりが出てくると思います。

PMFまでをいかに早く持っていくか

短期的にスピードが出る方だとBubbleの内部DBを使った方がおそらく早いです。
新規サービスはうまくいかないケースの方が多いので、作り変えることを考えすぎずに短期的に一番スピードが出る方法を採用するのはそれはそれでありだと思います。

作り直す場合でDBも含めて刷新するという前提があると、細かい設計を気にしないで進めやすいので、短期的にはよりスピードが出るんじゃないでしょうか。

Bubbleにもエンタープライズプランまで用意されているので、やってみた結果Bubbleだけでもやっていけそうというケースもあり得ますし。

作り変えるコストをいかに下げるか

作り替えることを想定すると、DBと認証周りについては外部サービスを使った方が圧倒的に楽ですしユーザーフレンドリーです。

• DBの移行をしなくて済む

• Bubble特有の設計をしない設計ができる

• ユーザーのパスワードをリセットする必要がない

あたりでしょうか。

Bubbleでは開発者がパスワードをさわれないようになっています。そのため、別のDBに移す際には一度パスワードは全てリセットする必要が出てきます。(一度ログアウトされる)

移行の手間とは別に、ユーザー離脱のポイントにもなりますよね。
BubbleのDBはBubbleから使うことに特化された作りになっている印象なので、テーブルの設計なども見直す必要が出てくるかもしれません。

最終的には結果論になるけども

作り変えるところまで事業がうまくいったら外部のサービスを使っておけばよかったとなるんじゃないでしょうか。
でも新規サービスがうまくいく可能性は、数字だけでみると高くはないはずなので、どこまで作り変えるところを見込むのかは人や会社によりますね。

その後の工数は大きく変わるので、いきなり作り始めずに少し検証をしてみてからでも良いのではと思います。

#bubble #bubble入門 #bubble初心者 #ノーコード #ノーコードツール #ノーコードアプリ