Firebase
cloudfunctions
Firestore

こんなFirebaseの使い方は間違っている (2019年4月版)


これはなに?

1年くらい業務でFirebaseと向き合って、本番運用もしている私が得た知見を雑にシェアすることにより、Firebase使っている人を優しい世界に導きつつ、昨今のFirebaseブームに乗じて増えているイケてないFirebaseの使い方紹介の氾濫を抑制してみようと試みるものです。

業務レベルでのFirebase利用を前提としたポリシーになっていますので、個人で使っているだけ&&動けばいいや思想の人は気分を害される前にここで回れ右してください。

Webを念頭に置いてますがiOS/Androidアプリでも同様と思います。


Disclaimer

この記事は2019年4月くらいの筆者の見解に基づくものです。だいたい間違ってないとは思いますが内容の正確性は保証しませんし、2ヶ月くらいするとFirebaseの進歩によりココに書かれていることが嘘になる可能性はあります。また、特定の記事や個人を中傷する意図はありません。筆者の所属する組織やその類とは関係がありません。


こんなFirebaseの使い方は間違っている

ここから本編です。

なぜダメかは解説しません。ダメな理由がわからないのであれば下に書いてある手法はあなたにとってバッドプラクティスです。真似してはいけません。ダメな理由をわかっている上でなお必要にかられて利用する場合は仕方ないかもしれません。


2019年にもなってRealtime Databaseを使っている

Firestoreをつかいなさい。


呼び出し可能なFunctionsを多用する

アプリケーション内部の処理で呼び出し可能なCloud Functionsを使うのは愚策です。

外部サービスの呼び出しをラップするくらいにとどめておくのが良いでしょう。


FirestoreへのRead/Writeオペレーションを呼び出し可能なFunctions経由で行う

Functionsの最悪の利用方法です。Firestoreの良さがすべて死にます。

Functionsを経由しなければいけないと思ったら、99.999%くらいの確率でデータモデリングをミスっているかセキュリティルールを理解していないかFunctionsの使い方が間違っているかのどれかです。


セキュリティルールの使い方がわかってない

Callable Functionsが濫用される背景はここにあると思ってますが、セキュリティルールを理解することを放棄するくらいならFirebaseを使わないほうが幸せになれます。セキュリティルールでできないことがFunctions噛ませただけでできると思っているのであれば大間違いです。


セキュリティルール内でユーザ権限の確認のためにget()関数を使う

ユーザの権限管理(adminとか)のためにセキュリティルールでget()関数つかって毎回Readを発生させるような作りは下手くそです。get()関数の安易な利用は金で殴れるアピールしたい人向けです。


どうすればいいの?

ここではないどこかで解説するのでみつけてください。

技術書典6で本を出そうと思っていたら抽選漏れて悲しみを背負ったのでどこか別の機会で。。。