要約
- RDBの考え方を捨てよ
- realtime databaseとも違う。具体的にはネストが深くてもOK
- セキュリティルール大事
- 現時点での感想
https://www.youtube.com/watch?v=v_hR4K4auoQ
急に色々と動き出してアワアワしてますが、絶対にやりたいアイデアがあるのでFirebaseをシコシコ勉強中。
結論から言うと「Firebaseすげえ」です。
もう使われてるのかもしれないけど、これからエンタープライズ領域でもガンガン使われるようになると思う。
現時点でわかったことを、主に自分の整理のために書きます。
1.正規化するな。
例えば、twitterみたいな投稿に対し「いいね」をつけるサービスを作るとしよう。
普通に考えると
Posts（投稿）
Users（ユーザ）
の2つのコレクション（テーブル）を作りPostsの中にuser_idを持つ。
で、ユーザのニックネームとかavatar画像とかはUsersから参照すると。
どうもこれがNGらしい。
Post投稿時にuserのニックネームとavatarのURLとかを一緒に格納するのがセオリーっぽい。
いちいち参照するとコストがかかるでしょと。
え、なになに？
じゃあuserのニックネームやavatarが変わったらすでに登録したPostを全部更新するの？
答えは「YESだ！」そうです（公式動画を見てくれ）。
参照と更新の頻度を考えると、webのほとんどが参照で更新はほんの少しでしょということらしい。
しかし、頭がRDB脳になってるので、そこで、もうムズムズしてしまう。
2.Cloud Functionsでラップするな。
firebaseにcloud functionsという機能がある。
これを使ってfire storeをRESTっぽく作りたいと思うよね。ワシも思った。
これもNGらしい。
遅くなるわセキュリティで考慮する点がふえるやらで、とにかくダメらしい。
なんのためにiosやらandroidやらjavascriptのSDKを作ったんだと。
そっち使えと。
でも、複数の処理をまとめたいとき（トランザクション的な動き）があるじゃないかと思ったけど、そういうのもきちんと準備してるんだと。
※此処らへんはあくまで読み散らしたところから判断してます。
後日ソースをきちんと書きますね。
3.セキュリティルールは超大事
開発時はユルユルでやりがちなんだけどここを間違えると即死レベル。
ドキュメント単位（RDBでいうレコード）でかけるか、コレクション単位（テーブル）でかけるか。
後から修正するとなると大変なのでよく練らないといけない。
ここはまだわかってないのでまた分かり次第更新します。
4.具体例
twitterのような、ユーザの投稿に対し「いいね」をつける場合の設計を考えてみる。
以下のBlogの説明が一番しっくりきた。ありがとうございます。
Cloud Firestoreで「いいね」機能を実装するときの勘所
要はどんどんサブコレクションを使ってネストしろと。
users(コレクション)
↓
id(ドキュメント)
↓
posts（コレクション）
↓
id(ドキュメント)※ここらへんに「contents」とか「imageUrl」とか「createdAt」↓
likedusers（コレクション）
↓
id(ドキュメント)※ここらへんに「nickname」とか「avatarUrl」とか「createdAt」
本家も似たような記述がある。
こんなにネストしたらドサッと帰ってきて平気で1Mの制限超えちゃうじゃん……。
と思ったらそうでもないらしい。
realtime databaseだとjson地獄になるんだけどcloud firestoreは大丈夫らしい。
サブコレクションの場合、参照だけ返す？ここらへんまだ理解できてません。
ただ上の設計がベストというわけではない。
これも人それぞれらしい。この記事も参考になった。
Cloud FirestoreとFirebase Cloud Storageを使ってソーシャル機能を実装する方法
5.感想
今まだ勉強中なんですが、イメージで言うとRDBと比較して
設計時のクリティカルパスがテーブル設計からセキュリティルールに移ったような気がしてます。
RDB時代はテーブル切って画面作った後に、カラム追加とかやろうものなら面倒くさいこと山のごとし！
これに対しfirestoreは何でも自由に放り込むことができる。
まあクライアント側のチェックで吸収できるレベルなのかと思う。
しかしセキュリティルールは、後から変えたらそれこそ
画面から作り直す必要がある？のではないか。
これは何回かやってみて痛い目に合わないとわからないです。
ちなみに、他にもupdate処理がSQLのようにガツンと一発で更新できないとか、
細かいところは色々とあるんだけど、一周回ってCOBOLの考え方だと思うと腑に落ちる。
むしろSQLでwhere句書き忘れて全件更新してしまったときに、
「なんで全部更新してまうん・・・」と「火垂るの墓」の節子のような気分
になるよりよっぽどマシかもしれない。
しかし、こういうビックウェーブが来るとうれしいです。
まさに「この年で挑戦者か・・・血湧く血湧く」です。
間違いなくこれは来るね。
今後、スタートアップ企業がwebサービスを作るとか言った場合に
まず最初の選択肢になると思う。
いや、もうなってる？失礼しました〜。