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の変更と同レベルのスキーマ変更が許容出来るようにソフトウェアアーキテクチャー も検討する必要があります。
まとめ
今回は、firesotreのほんの触り部分について、自社サービスに導入した際に感じたことなどをまとめて記載しました。まだfirestoreに関しては、紹介出来ていない部分も多いと思いますので、いずれ紹介できれば良いと思っています。