2020年くらいから今までfirestoreを業務や個人の開発で使用しました。
またいろんなエンジニアからfirestoreの良さや使い方についても教えていただいたので、
今回はそのTipsを皆さんに共有したいと思います。

コレクションはネストさせない

2~3年前はコレクションをネストさせていくのが主流？のような感じがしていましたが、この設計をしているプロダクトは軒並み開発しづらくなってる印象です。確かに、ネストしても取得しやすい関数やネストさせればfirestoreのリクエスト数が減るので便利な一面もあります。ですが、基本ネストはネストなので、開発者自身が読みづらく、ユーザーとの紐付きに関係なくネストされたデータを取得したいとなった時に困ります。また、ネストさせるとデータの更新頻度も増え結局、読み書きのリクエストは増えます。

【図で解説】Firestoreでできること・できないこと

Timestampは付けておいた方がいい

型は文字列でもいいのですが、日付を各ドキュメントで管理しておくのはおすすめです。
日付、時間まで管理することで並べ替えができたり、ページネーションを実装できます。
私は、firestoreで中間テーブルのようなものも作ってるのですが、そこにもcreateAtやupdateAtを追加して、検索結果の並び替えとページネーションを行なっています。

日付は文字列で管理していい

文字列で管理していても、検索可能です。
フロントにきた時はDateオブジェクトに変換しています。

日付の型の管理に気をつける

文字列で管理してもいいとは思いますが、
firestoreとサービスで型が違うと変換処理を挟む必要があるので地味に面倒です。
しかも、変換処理の漏れがあったりすると、firestoreとサービス上で型が一致してしまう時がありバグの原因になります。firestoreはこのように柔軟なので、ちょっと間違っても動いてしまうのが困るところでもあります。

whereを使うためのsplit関数を用意すると便利

firestoreのwhere-inは10個までの引数しか取れません。これはメール配信処理の時に困ります。
100個あるときは10個ずつの配列に分割しなければならないので、あらかじめ関数を用意しておくと楽です。

Relationの型を用意するとネストさせてないコレクションも使いやすい

コレクションを分けてドキュメントをバラバラで管理している場合は、サービス上でまとめる必要があります。
例えば、User.tweetsを取得する時に最初にUserを取得し、その後にuserIdでTweetsを取得します。
これがTweetsだけでなく、Likesまで必要となると管理が大変ですので、Relationオブジェクトでまとめてしまってます。

画像URLはトークン付きで保存していい

storageに保存した画像パスだけをドキュメントのフィールドに保存するのではなく、
tokenクエリまで一緒に取得すると、サービス上でgetDownloadUrlをしなくても済むので便利です。
本人確認書類のような画像データを保存する時は注意が必要ですが、そもそもそのようなデータは内部で管理しない方がいいです。

userIdとauthenticationのuidは共通で管理する

usersコレクションがauthenticationの認証情報も管理する場合は、ドキュメントパスはauthenticationのuidにすると取得が楽になります。

一部のテーブルだけコレクションで管理しない

NoSQL以外にrdbも使ったりして、連携する必要があるデータ別々のDBに管理すると、DB間のやりとりが発生して速度やパフォーマンスが落ちたりします。