Firestore導入前に 検討したかったベスト５

自己紹介 • さとう　たくと（ぽち） • 営業→エンジニア→人事→いま！！ • 髪をきりました... @pitown https://twitter.com/pitown

自己紹介 今はHotspringで2人目のエンジ ニアとしてやってます。 年始からエンジニアを募集したら 副業6人増えました！ 興味ある方は！ 仕事は、「ズボラ旅」というサービ スをつくっています。

自己紹介 ーズボラ旅ー LINEで旅行の相談ができるサー ビスです。 おすすめの提案をもらって、 そのまま予約まで。 ズボラな人程キモチいいです よかったら使ってね！

自己紹介 ーズボラ旅ー LINEで旅行の相談ができるサー ビスです。 おすすめの提案をもらって、 そのまま予約まで。 ズボラな人程キモチいいです よかったら使ってね！ 使っていただいた方、 ありがとうございます

自己紹介 そんなことより、みんなスマブラがアツいので、ただふつうにあそ びにきてください ぼくのガノンドロフが火を吹きます ここにがのんどろふの絵を描きたい なぁ

ちなみに (会場に本番投入している人きいたら1割 いなかったくらい？)

では本題

Firestore導入前に検討したかった ベスト５を見ていきましょう

注意 ここで紹介するのはあくまでも、 「チャット部分だけ」とか 「ツールで」とか そういう話ではなく、 FirestoreをメインDBとしてFirestore中心 に本番プロダクトを開発した時の話になりま す。(しかも当方web) 部分導入やツールとかは、使ったら？としか 言いようがないです！使おう！

第5位

どのくらい金かかるんよ？

どのくらい金かかるんよ？ • 面倒なので晒す 規模感(とある時) ・collection数: 12 ・全document数: 415,354 ・最多document: 297,879 実績(とある単月) • read 132,066,418回 ¥8,666 • write 181,163回 ¥18 • storage 2.218GB ¥24 • egress 65.876GB ¥751

第4位

うちに合うかなぁ？

①プロダクトに合うか • スキーマレスは、仕様変更したり、手で変更したり、ラベル付け したり、そういうものにめちゃくちゃ強い。ので、DB構造さえも ちょこちょこ変わりうるスピード感のプロダクトだとすごく強力よ ね • リレーション死ぬほど大事なプロダクトはさすがにミスマッチ。 でも、死ぬほどか？っていうと、死ぬほどなプロダクト、少数派 だとおもうんよ • データ構造のReadとWriteが同じ型が多いと楽ができるよ • 逆にそうならないときに、何かしらの一工夫が必要(同じ データを二箇所に持たせるなどの)。うちはCQRS風味にし ています

• 過度なRDB信仰だと枷になりうる • RDBならできるのに、、という形で、RDBに寄せに行ったら ただの劣化版RDBになるから負け • 活かすために、思い切りの良い設計と発想が必要 • ゼロベースで考えてやってみる人が必要 • 結局、アーキテクチャ全体に、分散型でスキーマレスで、と いう特性を与える。nullableだし、連番もNGだし。SQLも弱 い。そういうことをちゃんと理解してアプリケーションをつくら ないといけない • ただ、最後は要はノリなんじゃないか...？とおもっている ②チームに合うか

第3位

アーキテクチャを晒してくれ

User Staff ①最初期

User Staff ②いま Firestoreをトリ ガーに、 Firestoreに書き 込む

後日、アーキテクチャの説明は、こちらのQiitaに まとめました！ https://qiita.com/pochi-sato/items/04f38bb ed89e84184b52

第2位

起きたバグややらかしを全部晒 してくれ

• UTF-8とUTF-16に関するバグを踏みました。Readはおろか、 アクセスしようとすると何も返ってこないし管理画面も開けな かった(サポートに言ったら修正されてマージ済) • 緊急対応でデータつくったらデータ形式を間違って画面が真っ 白になった← • ローカルで全文検索してたら、すぐに使い物にならなくなってた だのボックスになった(Let’s Algolia)← • 1分くらい、「おや、、？書き込めてない、、？」ということが何度 かあった(年明けてからあんまり記憶ない) • まるっとexportしようとすると、データ上限にひっかかったり • サーバサイドでリアルタイムアップデート張りっぱなしにしてた ら、たまにコネクション切れた← • サーバサイドでリアルタイムアップデートしてたらスパイクした ときに死んだ←

バグ、やらかしに関しては、 ほとんどが、自分で特性を理解して 適切に対処すれば防げるもの ばかりでした、今の所。 (UTF-8以外は)

第1位

ねぇ、そこのFirestoreをアプリ ケーションのメインDBとして本 番で運用しているあなた！ ぶっちゃけ、オススメな の！！？？ どうなの！！！！？？

実際、 • リリース5分で4000人がなだれこんでくるようなサービスでも、 フロント/バックエンド/インフラ、まるまる含めて1人で1ヶ月で実 装が完了できた！ • その後も、リアルタイムアップデートとか駆使しつつ、フロントも バックエンドも一切キャッシュ機能をつくらずにスケールできた • クライアントジョイン問題でめちゃくちゃパフォーマンス劣化しつ つも、データ構造を素直にしてあげると爆速を取り戻し、未だフ ロントでキャッシュ化の必要ない！ • 構造の柔軟さに、緊急対応で死ぬほど助けられた...

デメリットは、スキーマレスで分散型でクエリが弱いDBに対し ての向き合い方。 決してそれはデメリットというよりも、特性の話というのが僕の 見解です。 それに対して、メリットがめちゃくちゃ強力なんです。 とにかく強力。 強力ゆえに序盤はパワープレイもかなり可能... (だけどスケールするとちゃんとした設計をあとで求められま す) 少人数で、立ち上がり速度が早く、しかも仕様変更が多いとき なんかは特にありがたみを感じられるとおもいます！

つまり

オススメです！！ (でも、ハマりどころを情報交換しよう！)

おわり 情報交換しましょう！ Firestoreこれからやるひと、 やってるひと、 話しましょう！ @pitown https://twitter.com/pitown