こんにちは！Diverse広報担当です。
先日、Diverse Meetup #1となる『Cloud Functionsを開発担当が徹底解説！』の前半の模様を公開しました！
マッチングアプリHOPの開発に携わる村本 章憲さんがご登壇。Cloud Functionとは何かという基本的内容から、参加者からの高度な質問への回答まで、たっぷり1時間かけてお話いただきました。
こちらの記事では、そんなイベントの後半の模様、主に質疑応答パートを余すところなくお伝えします！
当日の資料と動画を共有します
残念ながら当日参加していただけなかった方のために、資料と動画を公開させていただきます！
イベントルポを大公開します
ここからは、当日のイベント（後半）のエッセンスを文字にまとめています。「動画を見ている時間がない！」「要点だけサラッと理解したい！」という方はこちらをご覧ください！
質問）今はドメインベースで切っているんですか？（00:00）
参加者：CallableとかFirestoreではなく、今はドメインベースで区切るのですか？
村本 章憲（以下、村本）：今はそう変えてますね。
Callable Functionに関しても、そのCallable Functionはどのドメインで呼ばれるものなのかを意識してます。
ドメインが必要なくなったときに全部が消えることが理想で、Callable Functionだけが別のところに取り残されるのを防いでいます。
質問）複数ドメインを跨ぐことはないんですか？（00:51）
参加者：複数のドメインを跨ぐようなファンクションなどが発生することはないんでしょうか。それとも、そういうことが起きないように設計をしているのでしょうか。
村本：例えば、今回のソーシャルっていう機能はusersのFirestoreに依存してますよね。
usersの下にactionsがある前提でクラウドファンクションを組んでいます。
また、チャット機能で考えたときは...
roomの下にメッセージが溜まるFirestoreを考えました。
メッセージの新規追加をユーザーに通知したいとき、notificationという新しいドメイン作ります。roomの中に新しい機能を書き加えるんじゃなくて、変更を見てnotificationに何かをするって感じなので、いらなくなったらnotificationだけ消せますよね。
逆に、チャット機能を消したとしてもnotificationには影響出ないの分かりますか？消えてるのでもう呼ばれなくなるんですよ。ゴミとしては残るかもしれないんですけど、運用に関しては全く問題ないです。
参加者：それぞれのファンクッションに依存関係がないように設計して、片方消しても全く問題ないようにドメインを分けていく感じですか？
村本；そうですね。依存しちゃダメなので、依存しないように作るって感じです。
質問）クラウドファンクションの型の管理はどうしている？（04:13）
村本：これは、もしかしたら開発チームによるかもしれません。
僕の場合、クラウドファンクションだけはFirestoreの型を持っていますが、クライアントは持たせていません。サーバーサイドとクライアントサイドで型を一致させる必要は、最近はないと思っています。
Twitterで考えてみましょう。
これは表示するのに必要なTweetのオブジェクトじゃないですか。
逆に、表示じゃなくて投稿するときには、
極端な話、これで良かったりしますよね。
読みたいものと書きたいものって、オブジェクトが別々だったりするんですよ。
これを書きたい時も「完全に一致させましょう」としちゃうと、管理が大変になると思うんですよね。
例えば...以下はツイートした側のFirestoreです。
読む人には、別のコレクションを読ませます。
参加者：ツイートしたときに、そこに一緒に書き込ませるようにするということですか？
村本：実はそうではなく、そこに登場するのが、クラウドファンクションなんです。
こうしておくと、ここに入れるのはこれでOK。uidで誰がツイートしたかわかります。
ここに、クライアントサイドでジョインしなくてもいいように、これを足してあげるんです。
そうすると嬉しいのは、まず、クライアントサイドが開発するときにテキストとこうするだけでいい。これはすごい楽ですよね。また読み込む側も、この形だけ持っていたら、ずっとこれをリードすればいいわけです。
twitterって今、フォローした人全員のツイートが入ってきますよね。
この中で関心高いものだけフィードにバラ撒けばいい。
そうすると、クラウドファンクションで、ユーザーに対してのフィードの表示の優先付けを管理できるんです。
これをFirestoreに全部任せようとすると、Firestoreのソートが貧弱なので、うまく機能しないんです。基本的にはwriteするものとreadするものは分けて考えたほうが良い。ただ、ここのFirestoreに入ってるデータは一致させる、こういうものが入るんだ、だけイメージしておく。
質問）整合性が合わなくなったりしないんですか？（09:34）
村本：こっちのバージョンも、V1ではこうでした、ってやってますよね。
V2では、メッセージの投稿をできるようにするとなると、クラウドファンクションはV2のものが出てきますよね。
こっちも同様に2を準備してあげる、もしくは1に入れちゃっても大丈夫です。
何故かというと、増える分には不整合は起きないんですよね。
このテキストが消える場合は、型が変わったことになりますけど、イメージが新しく追加されるのは問題ないわけです。
この方法でやると、V1のものも運用可能ですし、V2になっても平行で運用可能ですね。
質問）型は共通のところで持つのでしょうか？（10:48）
参加者：クライアントからテキストとイメージを投げるときに、タイプスクリプトであれば型を作っておくと思うんですけど、それって共通のところで持っているんですか？
村本：持ってないです。
僕はクライアントとサーバーは切り離して考えてます。昔、一緒にできるようなライブラリ書こうかなと思って書いてました。ただそうすると結局、運用方法が間違ってるというか、サーバーとクライアントでは仕事が違うので。一緒にさせない方がいいねっていう結論に至ってますね。
それぞれに書くほうがいいと思います。
さいごに
ここまでお読み頂き有難うございました！
今回で、前編後編通してのイベントルポが終了しました。ミートアップは今後も実施してゆく予定なので、予定が合う方はぜひご参加ください！
なお、Diverseはこのようなイベントの他にも各所で情報発信を行っています。興味のある方はぜひ覗いてください！
