Firebaseは良いけど辛い/2019-03-27-llt8

社内のLTイベント「えるLT Vol.8」で発表した資料です

Transcript

1. Firebaseは良いけど辛い Satoshi SAKAO えるLT Vol.8 2019/03/27 (Wed) I1
2. 話すひと I2 インフォコム株式会社 オープンイノベーションセンター " アプリケーションエンジニア JS (ES6) / Node.js / GCP / IoT / iOS (Swift) フォーカスリーディング / 技術士合格に向けた学習 Satoshi SAKAO @ottijp
3. 話すこと • Firebaseはいいぞ • ユースケースを考えないとうまくハマらなくて詰むかもしれない • ※ 2017年の話なので注意 I3
4. I4 2017年にやっていた企画と検証システム
5. 認知症ケア支援サービス I5
6. 初期の構成 I6 Z-worksとの連携をHerokuにサービスを置いた その他はFirebaseで完結させようとしていた
7. Firebaseはいいぞ • サーバサイド実装，インフラ管理が不要 • データストア，ファイルストレージ，プッシュ通知，
 認証，アナリティクス，FaaS • Realtime Databaseがすごい便利（NoSQL+WebSocket） • こりゃあFirebaseだけでいけるぜ！ヒャッハー！！ I7
8. I8 終わりの始まり
9. RTDBの制約が真綿のように首を締め始めた • 外部キー制約が付けられない • ソートが特定キーのみでしかできない • フィルタリングが限定的 • マイグレーションの辛さ • 同一データパスに対するビジネス条件による
 アクセス制御の実現が困難 I9
10. なんとかすればFirebaseだけで頑張れるんじゃないかという意地 • Cloud Functionsでロジックの実装 • Flashlight(ElasticSearch) で検索の補完 • ※結局別のコンピューティングインスタンスは必要 • Cloud FireStoreの誘惑 • 当時PJの後半くらいでちょうどリリースされた I10
11. 最終的な構成 I11 RTDBでは辛い部分はHerokuに逃げた 認証はFirebaseのみに留めた
12. I12 失敗と学び
13. 失敗と学び • RTDB（NoSQL＋リアルタイム同期）はすごい便利だけど，
 結局Pros/Consとユースケースを考えて使わないと死ぬ • Herokuを主，Firebaseを従として，
 FirebaseをうまくMBaaS的に使えると良かった • スタートガイドだけではなく，もう少し実現したいシステムに
 近い具体的な実装を試してみて，適合性を判断すべきだった • 仮説検証システムでまだ傷が浅くてよかった？ I13
14. $ exit I14