RDB脳からFirestore脳へ

Transcript

1. RDB脳からFirestore脳へ 2022/3/7 LT ham
2. Firestoreとは • Firebase(Google Cloud)で提供されているNoSQLデータベース • フロントコードから直接呼び出すことができるため、バックエンドの構築が 不要。 • 料金は保存量＋READやWRITE数で決まる従量課金だが、無料枠がありサクッ と使うだけであれば無料枠におさまるのでプロトタイプ開発や個人開発での 使い勝手が良い。
3. RDB脳からFirestore脳へ システムでデータの保存先と言えば、PostgreSQLやMySQLなどのリレーショナ ルデータベース(RDB)が主流です。 そのため、システム開発したことがある方はRDBの知識を持っている方が多いの ですが、RDBの考え方をFirestoreにそのまま適用するとうまくいかないこと/ 面倒なこと/そもそもできないことが多々あります。 そこで、このスライドではRDBとFirestoreで考え方を変えるべき例を2つ紹介 します。
4. アクセス範囲に合わせてテーブルを分ける 例えばユーザー情報を管理するテーブルを考えます。 保持する情報は下記の通り。 • ニックネーム ◦ 全体に公開OK • メールアドレス ◦ 本人のみ閲覧OK
5. アクセス範囲に合わせてテーブルを分ける RDBの場合 usersテーブルに nicknameとemailを保持 users ・nickname ・email バックエンド クライアントからバックエンドを通して RDBにアクセスするため、同一テーブル に入っていてもシステムでアクセス制御 可能
6. アクセス範囲に合わせてテーブルを分ける Firestoreの場合 usersドキュメントに nicknameとemailを保持 /users ・nickname ・email レコード単位でルールを設定しアクセス 制御するので1レコードにアクセス範囲 が異なるデータが入っているとアクセス 制御が困難 ルール
7. アクセス範囲に合わせてテーブルを分ける Firestoreの場合 nicknameとemailでドキュメントを 分ける /private_users ・email /users ・nickname ルール ルール ドキュメントを分けることでそれぞれに ルールを設定可能
8. 用途ごとにテーブルを作成する 複数のリソースを持っており、画面によって必要な情報が異なる場合を考えま す。 画面A:usersのみ使用 画面B:usersとそれに関連するuser_hogesを使用 画面C:usersとそれに関連するuser_fugasを使用 画面A 画面B 画面C users users └user_hoges users └user_fugas
9. 用途ごとにテーブルを作成する RDBの場合 リソースごとに テーブル管理 users バックエンドで必要なデータをDBから取 得して整形して返却 A B C user_hoges user_fugas バックエンド users users └user_hoges users └user_fugas
10. 用途ごとにテーブルを作成する Firestoreの場合 /users A B C /user_hoges /user_fugas users users user_hoges users user_fugas リソースごとに ドキュメント管理 バックエンドがないため、データの整形をク ライアントが実装する必要がある。 また、RDBのように適切にjoinしてリクエスト を減らすことが難しくREAD数も増える (READ数課金)
11. 用途ごとにテーブルを作成する Firestoreの場合 /users A B C /user_hoges (with users) /user_fugas (with users) users user_hoges user_hogesやuser_fugasに users情報を含める。 クライアントが使いやすい形に整 形しておく。 あらかじめクライアントが使いやすい形に整 形してあるので、クライアント処理がシンプ ルになり、READ数も減る。 user_fugas 参照処理はシンプルに なるが、更新処理が煩 雑になるのでは？
12. usersが更新された場合 用途ごとにテーブルを作成する /users /user_hoges (with users) /user_fugas (with users) usersが更新された時、user情報を含んでいるすべてのド キュメントを更新する必要がある。 →クライアントがuser情報を持っているドキュメントを把握し ておく必要がある →処理が煩雑に・・・
13. usersが更新された場合 用途ごとにテーブルを作成する /users /user_hoges (with users) /user_fugas (with users) クライアントからはusersのみ更新 Cloud Functions usersの更新を検知して、user_hogesや user_fugasを更新 →クライアントはuser情報を持っているドキュメン トを把握する必要がなくなる。
14. 参考書籍 Firestoreのドキュメントだけでは読み取れない、実践で役立つプラクティスが 書かれている本。 私はこの本を読んでFirestore脳ができました。 Firestoreを使ってみようと思っている方は一読の価値があると思います。 (ちなみに私はこの本の関係者でもなんでもありません) 実践Firestore