こんにちは、最近、CloudFunction を 0->1 で導入することになった Nash です。
この記事では、「Firebase CloduFunctions のトリガーについてのディレクトリ設計」のまとめです。
CloudFunctionトリガーを0⇒1で入れてるのでディレクトリ設計してみたけど、以前の現場ではFirestoreのパスに対して実行されるファイルが「ディレクトリ構造」で表現されてて、それだとネストが深くてツラかったので、今回は1階層にしてFirestoreのパスを全部「ファイル名」で表現してみる
— Nash⚡️ReactNative書いてる (@snamiki1212) May 22, 2020
考えた結果は下記の 3 案になります。
では、見ていきます。
(ちなみに、便宜上は Firestore について言及してますが、Realtimedatabase でも可能です)
先に結論です。
3 つの案について見る前に、ディレクトリ設計をする理由などについて簡単におさらいします。
Firebase で提供されている Firestore と CloudFunction のトリガーを組み合わせると、
ということが出来ます。
そのため、下記についてのマッピングを考えます。
それぞれが紐づくわけですが、B)の設計についてこの記事では考えます。
では、各案を見ていきます。
一番、一般的なやり方かと思います。
version/v1/users/index.ts
のようにディレクトリ配下にトリガーファンクションのファイルを管理します。
こんな感じ。
helper.ts
などを近くに起きやすいネストが深くなる
規約違反な書き方・置き方をしていても漏れやすい
普通に設計するとこの構造になるかと思うのですが、上に挙げたデメリットの負の部分が大きいと思っているので、個人的には案 2)か案 3)が良いかと思ってます。
最近、試していて個人的に気に入ってます。
version.v1.users.{user_id}.ts
のようなファイル名でトリガーファンクションのファイルを管理します。
こんな感じです。
メリデメは下記かと思います。
「あるストレージパスの配下だけで使う helper.ts」みたいのを定義できないです。
/triggers
の外のパスに出して/src/helper.ts
とかに置いてここを参照するような感じになるかと思います。1 つのストレージパスに対して複数のファイルを置くことができないので、大規模になると辛そうですが、小〜中規模ならメリットのほうが大きいと思ってます。むしろこの置き方のほうが制限ができるのでカオスになる可能性がなくなりますしね。
ちなみに、ファイル名による規約化も簡単にできるので規約化しちゃうコードを書くのもありかもです。
version.v1.users.{user_id}/index.ts
のようにフォルダ名でトリガーファンクションのファイルを管理します。
こんな感じです。
メリデメで列挙すると下記かと思います。
比較で考えると、「ファイル名で表現する案 2」と比較して、1 層多くディレクトリを切るので複数ファイルを格納することができるようになります。
なので、
helper.ts
を置きたいみたいなことができるようになるので、中〜大規模のときに向いてるのかな、と思います。
いろいろ設計を考えてみました。案 1)で実際に開発していた経験はあるのですが、案 2)・案 3)ではあまりゴリゴリ開発した経験がないので、ここに書かれている以外の隠れた問題があるかもしれないです。
あと、案 2)のファイルで設計する構造のときに規約化するロジックもまとめたのでこちらでどうぞ。