「実践 Firestore」を読んだ読書メモ

感想など

RDB のスキーマ設計は適切に正規化をすれば大体おかしいことにはならないと思っているけど、NoSQL はその辺が難しいと思っていた。

特に FireStore はクライアントから直接接続を行うため、値のバリデーションと、アクセスコントロールを設定で行わないといけない。

アクセスコントロールは基本的に穴を空けていくものなので、適切にスキーマ設計をすることで必要以上に穴を空けなくてすむようになる。

さらに FireStore は従量課金だ。不要なアクセスを減らすようなスキーマ設計やクエリを記述する必要がある。

そのあたりを踏まえたスキーマ設計やセキュリティルールの設定方法について記述されている。

セキュリティ観点では、そもそもコレクションを分けてしまうという戦略が一番よいらしい。 例えば、ユーザの情報でもニックネームなどの公開可能情報以外にメールアドレスなど本人以外にアクセスさせたくない情報がある。

そのような場合は、/private-user/<uid> と /public-user/<uid> にスキーマを分けて同じ uid を ドキュメントの ID とする。

加えて、ユーザと 1:n 関係を持つ情報がある場合 (ログイン履歴とか) ユーザのサブコレクションにするわけだが、これも、公開するかしないかで、どちらかのサブコレクションにするのがよい。

トップレベルに新しいコレクションを作成してドキュメントのフィールドに参照を持たせるという戦略もあるようだが、コレクショングループクエリ が書けるようになってからこれを行うメリットはあまりなくなったらしい。

セキュリティルールではドキュメントのバリデーションも行い、不正な値が入らないようにする。セキュリティルールはシュミレータで試験ができるらしいので、テストを書きながら管理するのがよさそう。

複雑なセキュリティルールは管理が難しいので、そのような処理は Function にして、 イベントにフックして、Adomin Client で操作するのが良いらしい。 ただ、この方法はリアルタイム性を損なうことになるので、要件に応じた対応が必要らしい。

この辺を踏まえて、今作ってるアプリのストアを再設計して実装していこうと思う。

久しぶりに新しい概念に触れて面白かった。