質問
Firestore(Document DB)の基本的な設計の考え方について紹介します。
更新: 

このドキュメントでは 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 を使います。

見ることができる人を制限したいドキュメントは FirebaseAdmin でしか取得できないように設計して下さい。

Client は誰でも見れて良いデータだけを触れるようにして下さい。

見ることができる人を制限したいデータや、一部の人にだけ更新が許可されたデータを操作するときは API 側で Firebase Admin SDK を活用して下さい。

例外として Client のユーザーだけが更新できるデータについては後述の Security Rule を活用して Client で更新して大丈夫です。

Security Rule を使って閲覧権限を制御する

Firebase では、Security Rule を使って閲覧権限を制御して下さい。

https://firebase.google.com/docs/firestore/security/get-started

基本的には誰でも見れて良いデータと、見れる人を制限したいデータはどドキュメントを分けて管理するようにして下さい。

この記事が気に入ったら応援お願いします🙏
2
ツイート
LINE
Developer
Price Rank Dev
I use Next.js (React) and Firebase (Firestore / Auth) for development. We are also developing APIs for Ruby on Rails and GraphQL. Our team members are 6 Vietnamese and Japanese engineers.