脱Firestoreするために考えていること（追記あり） - Sweet Escape

FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対

[tivrsky]

Firestoreのスタートは神がかり的に速いけど非機能要件と集計の問題がすぐやってくる大きな技術的負債なんだよな

[c-matt]

ホットなデータはFirestoreに、コールドなデータはPubSubに流してRDBやBigQueryに格納して集計してる。ある程度機能が成長するまではFirestoreのがやっぱり楽なんだよなー

[takezaki]

脱FirestoreとGraphQL見送りはいい判断だと思う

[USuck]

悪いことは言わないので初手GraphQL考えた方が良さそう。この理由でFirestore→RDB+RESTに乗り換えるってことは3年後には確実にRESTからGraphQLに乗り換えたくなってる。

[h5y1m141]

自分でこういう経験すること無さそうだけどめちゃくちゃ参考になる！前に経験したプロジェクトで仮に今、脱Firestoreとなったらセキュリティルール＆CloudFunctions連携処理とか色々考慮ポイントありそう

[twotiger]

中国とかだとGCP使えないのかな。Firebaseはベンダーロックインすぎる

[mysql8]

RDBしか勝たん