このドキュメントでは Document DB の Firebase / Firestore における基本的な設計の考え方について紹介します。
Firebase は学習途中でまだまだ知識不足なので間違っている点があるかもしれません。また経験を積み重ねていきながら記述を修正しています。
Firestore をつかう前提として
Firestore は NoSQL (Document Database) です。デザインをするときには Firestore、NoSQL の実装のルールやセキュリティの考え方を意識して下さい。
Basic Design Rule
表示に合わせてドキュメントを設計する
ドキュメントDB の場合は、表示に必要なデータをオブジェクトに詰め込むようにして下さい。一回の取得で表示に必要なデータが取得できるようにドキュメントのフィールドを設計して下さい。
Firestore はロードが遅い
Firestoreは、分散型のドキュメントDBなのでロードが遅く、時間がかかります。 また読み込み回数に応じて料金がかかります。
https://firebase.google.com/docs/firestore/pricing
それを踏まえて、できるだけロードの回数を抑えるように実装して下さい。
また、Next.js の Static Site Generation (SSG) や Incremental Static Regeneration (ISR) を活用して、Firestore のロードの遅さがユーザー体験に影響を与えないように実装しましょう。
Firebase Client と Firebase Admin SDK
Clientは Firebase SDK、 API は Firebase Admin SDK を使います。
- Firebase Client: https://firebase.google.com/docs/firestore/client/libraries
- Firebase Admin SDK: https://firebase.google.com/docs/admin/setup
見ることができる人を制限したいドキュメントは FirebaseAdmin でしか取得できないように設計して下さい。
Client は誰でも見れて良いデータだけを触れるようにして下さい。
見ることができる人を制限したいデータや、一部の人にだけ更新が許可されたデータを操作するときは API 側で Firebase Admin SDK を活用して下さい。
例外として Client のユーザーだけが更新できるデータについては後述の Security Rule を活用して Client で更新して大丈夫です。
Security Rule を使って閲覧権限を制御する
Firebase では、Security Rule を使って閲覧権限を制御して下さい。
https://firebase.google.com/docs/firestore/security/get-started
基本的には誰でも見れて良いデータと、見れる人を制限したいデータはどドキュメントを分けて管理するようにして下さい。