Firebaseで失敗した

FirebaseのRealtimeDatabaseを使ったときに失敗したことがあったので書きます。
なお、この体験はハッカソン等での個人の体験であり、 実サービスとは関係ありません。
また、関わったエンジニアの方々を馬鹿にしたいわけでなく、同じ失敗を繰り返さないために自分用のメモとしても載せております。

わかること

• Firebaseを利用するときの失敗例から導入すべきかどうか
• 責任問題やできることできないこと
• 工数は本当に下がるのか

要件

• 即反映したい、システムを作るという要件があった
  • 投稿 -> (何かしら操作) -> (何かしら操作2) -> 反映 といういろいろ経由するけどなる早がいいとのこと
    
• 件数は数1000万件?ほど予想であり、webのpub/subやwebSocketでも良かったが、「サーバーサイドの負荷が楽になる＋フロントエンドも実装が楽になる+かっこいい」という見込みを立てて、FirebaseのRealtimeDatabaseを選択
• 実装するための期間も非常に短かった

実装作戦

• 匿名ログイン周りは、FirebaseFunctionでTokenなどを発行して処理(サーバー)
• あとは、フロントでデータを突っ込んでもらったり、出してもらったりする想定で進める

サーバー担当

• ログイン周り
• Firebaseのルール

フロント担当

• DB設計
• データ管理
• 該当のシステムの画面
• 何かしら操作の画面

という感じで、普段サーバーサイドがやっているDB設計などもフロントに投げてしまった（助言程度） <= ここが良くなかった。

失敗したこと

• マークアップエンジニアに、データ管理や設計を任せてしまったことにより、データの取扱のところでミスが出てしまい、 大規模な障害とバグにつながってしまった
• データをサブスクライブしておけばデータが来ると思っていたらしく、 実装待ちになって進んでいなかったときがあった
• データの取扱の工数感がサーバーに比べてないため、工数を軽視されていた
• DB設計やソート、カウント、limitを取るという知見がないため、スロークエリになりがちな実装も見られた
• NoSQLはサーバーサイドエンジニアであればDynamoDBなどでもよく使っていたが、マークアップを専門に行なっているフロントエンジニアにとっては少しハードルが高かった
• フロントのViewのソースコードとデータ周りのプルリクが同じなので、サーバーでのプルリク確認がし辛い

まとめ

• FirebaseのRealtimeDatabaseはとても便利で、実装も早くなるし、サーバーサイドの実装工数が減る が、フロントエンドに責任を押し付けてしまう事になり、実サービスや重要案件の場合は気をつけたほうがいい
• 責任分散がやりづらい
• 大規模なサービスになると、実は工数はあまり変わらない
• ログが残りづらいのでたどりにくい(意外と重要)

合わせて

• 「DynamoDBを使うサーバーレス設計で失敗した」という記事も公開しました