この章はおまけとなります。
Firestoreのパブリックβ公開から現在に至るまでFirestoreを使った開発に従事し、セキュリティルールの進歩を見てきた自分だからこそ話せる昔話をいくつがご紹介します。
当初はリファレンスの情報がほとんどなかった
Firestoreがパブリックβで出た当初は、セキュリティルールに限らずドキュメントが不足していたので、どのように記述すればいいのか手探り状態でした。
セキュリティルールに関しても、Getting Startedと本当に基本的なルールの書き方程度しかドキュメントがなかったため、自分の開発するサービスに合う形でルールを書くのが大変でした。
セキュリティルールのデプロイ=>適応まで最大10分...?
今ではセキュリティルールのデプロイから適応まで１分程度で済むため、少しの変更でもどんどんデプロイすることが可能でした。
しかし昔はデプロイしてから最大10分かかる可能性があったため、デプロイ自体慎重に行う必要がありました。
そして昔はFirebaseコンソール上にRulesプレイグラウンドはなく、Firestoreエミュレーターもなかったため、適応されたかを確認するには開発中のアプリケーションで動作確認する必要がありました。
しかし適応までの時間がかかるため、「やっぱりルール間違ってたか...」→(数分後)→「あれ、何もしてないのに動くようになった」みたいなことが度々発生しました。。
数行の変更でも嵌ると２時間くらいあっというまに溶けてしまったこともあります。
セキュリティルールテスト用のFirebaseプロジェクトを用意していた
Rulesプレイグラウンドもない、Firestoreエミュレーターもない時代。流石に人力で、開発アプリを使ってセキュリティルールが正しく動作するかをテストするのは厳しくなってきたため、テスト用のFirebaseプロジェクトを作り、そのプロジェクトにセキュリティルールをデプロイして適応し、Firestoreに直接書き込んで「Permission Denied」が起きないかを確かめるようなテストを書いていました。
当時著者が書いたブログがこちらです。(今はこの方法は推奨しません。)
writeFieldsってのがありまして...
昔はありましたが、2018年にDeprecatedになり、最終的には削除されました。今はMapDiff型を使います。