firestoreをサービス開発に導入して分かったこと

firestoreは、firebaseが提供するサービス郡の1つでNoSQLドキュメント指向データベースと言われています。
firestoreを実際に利用する場合には、下記のドキュメントに目を通すと良いと思います。基本的には前者のドキュメントに目を通せば良いと思います。

firestoreの誤解していた部分

初めてfirestoreを利用してプロトタイプやサンプルコードを書いた時には、「NoSQLドキュメント指向データベース」と呼ばれている部分にしか考えていなかったのですが、この部分は、firesotoreの一部分に過ぎないということが分かってきました。

従来のDatabase操作を伴うアプリケーションアーキテクチャー

Databaseを伴う多くのアプリケーション開発時に採用されるアーキテクチャーは、Databaseアクセスに関しては、下記のような要件で実現されることが多い気がします。

APIを操作して、必要なデータを追加、削除、編集する
APIの内部でデータへのアクセス権限のチェックをする
データベーススキーマの変更は、なるべく行わない。

firestoreでは

firestoreの大きな特徴は、「クライアントサイド」からSDKを利用して、直接データにアクセス出来るという点です。これは、従来のアプリケーションアーキテクチャーと大きく異なる点です。これを実現する為にfirestoreでは、以下の機能を提供しています。

セキュリティールール
リアルタイムリスナー
イベントトリガー(Cloud functions)

セキュリティールール

従来のAPIで行っている認証チェックに相当します。

リアルタイムリスナー

firesotreで管理しているデータに変化があったことを受け取ることが出来る仕組みのことです。サーバサイドの状態変化を受け取る仕組みとしては、ポーリングと呼ばれるクライアントからデータを取得して、取得したデータに差分がある場合に描画を更新するといった方法や、websocketなどの技術を利用して、サーバ側のデータが変化したタイミングを通知して、描画を更新するなどの技術がありますが、ポーリングでデータ取得する場合には、不要なタイミングでもデータを取得してしまう為、無駄が多く発生してしまいます。firestoreのSDKが提供するリアルタイムリスナーは、サーバ側に変化があったタイミングで通知してくれるので、効率的です。

イベントトリガー(Cloud functions)

こちらは、データの書き込み、削除、更新などのタイミングで必要な処理をcloud functionを通じて出来るので、従来のような専用のAPIを実装する必要がありません。

スキーマ変更について

従来のアプリケーション開発において、スキーマの変更をすることは、かなりハードルが高い印象がありました。スキーマを変更するぐらいなら、セッションなどを導入して状態を保持するなど、API 内部で解決出来る場合は、基本的にスキーマ変更は行わないようにする傾向が強いイメージがありました。今回のfirestoreでは、クライアント側からスキーマを変更出来るので、従来のAPIの変更と同レベルのスキーマ変更が許容出来るようにソフトウェアアーキテクチャーも検討する必要があります。