2019/10/04 に公開1061 views
@potato4d と @spring_raining が、個人開発者の @oliver_diary と共に小規模チームにおける Firebase、Firebase を使って嬉しかったこと、Firestore のルールのつらさ、Extensions、IaC について語りました。
ゲスト紹介
- おりばー
- https://twitter.com/oliver_diary
- とある会社の Developer
- 個人開発者
最近の Firebase の利用状況と便利ポイント
- potato4d が最近 Rails to Firebase を行った
- Firebase を仕事で使うことが増えてきた
- LINE では使うことがあまりないけれどそれ以外では Firebase の仕事も割とある
- Contributter という GitHub の Contributions を Twitter に流す Web アプリケーション
- https://contributter.potato4d.me
- 元々は Ruby on Rails で作っていた
- たまたまその時期に Rails を触っていたため
- 収益性を求めない個人開発だと RDS 高くて辛い
- Heroku Scheduler が遅延して辛い
- Next.js + Firebase に移行
- Firebase に cron が来て実現可能に
- cron で enqueue だけおこなって Functions の onCreate で処理
- Firebase を仕事で使うことが増えてきた
- spring_raining は DeepGlyph にて利用中
- Firestore 以外だいたい使ってる
- おりばーも最近 Firebase で使うことが多くなっている
- 元々 Ruby on Rails でサービスを作ることが多かった
- 最近は便利じゃんとなって使うことが増加
- Rails のつらさと戦うことも多かった
- 最近は便利じゃんとなって使うことが増加
- 新規プロダクトでも Firebase 利用中
- spring_raining と共に開発中
- Twitter API と連携する形で Firebase を全力で活用
- Functions で定期的な Twitter API へのアクセス
- Twitter API のアクセス結果は Firestore に格納
- Firestore との連携を考慮した Functions も活用中
- いいねボタンを押したときにデータを反映する処理
- 元々 Ruby on Rails でサービスを作ることが多かった
Firestore のルールについて
- Firestore のルールどうしてるか
- Firestore のルールでアプリケーションのパターンは網羅できる
- 如何に大変さを許容するか？が論点に
- どこまで Functions で守るか
- Read だけ Firebase SDK、Write は Firestore
- Pros: 安全、Readでリアルタイム性は担保できる
- Cons: コールドスタートが辛いのとパフォーマンスが良くはない
- 基本全部 Firestore
- Pros: 真価を発揮できる
- Cons: 少しのミスが致命傷に成りうる
- ユーザーのネームスペース上だけ Firestore で Shared は Functions
- Pros: 基本はハイパフォーマンスかつ安全、いいね数のようなSharedは遅延と結果整合を許容できる
- Cons: 設計の塩梅が難しい
- Read だけ Firebase SDK、Write は Firestore
- Firestore のルールでアプリケーションのパターンは網羅できる
- Firestore のルールを書くエディタについて
- Firestore のルールは JavaScript によくにた JavaScript ではない言語
- 独自 DSL なので syntax ハイライトが弱い
- VSCode を使うと便利
- Firestore 用の syntax highlight がプラグインとして存在する
- https://marketplace.visualstudio.com/items?itemName=toba.vsfire
- Firestore のルールは JavaScript によくにた JavaScript ではない言語
Firebase のプランについて
- プランの話
- みんなプランどうしてる？
- おりばーは Spark や Frame が多く、最近 Blaze もたびたび利用
- Spark で済むなら Spark にして Frame も利用。最近は Blaze も増加
- potato4d と spring_raining は初手 Blaze がほとんど
- 人気が出なければ 25 ドルもかからないし出たら収益でペイするスタイル
- 共通してそもそも安いのであんまり気にしてない
- おりばーは Spark や Frame が多く、最近 Blaze もたびたび利用
- どういうときに課金にするか
- Functions から Outgoing の通信をするとき
- そもそも書き込み量が予想されるとき
- 学生時代はそもそも課金が壁
- クレカ登録したくない話
- ちなみに……
- UIT meetup vol.7 で行った「いいね」システムは 100k R / 30k W で 50 円程度
- おりばーが最近個人プロダクトで 240k R をしたときで 10 円単位
- みんなプランどうしてる？
Extensions への期待
- Firebase Extensions が便利そう
- https://firebase.google.com/products/extensions
- Firebase でよく実装することになったり欲しくなる機能を拡張として提供
- 退会時のユーザー全削除、画像リサイズ、自動翻訳、メール配信など……
- おりばーは写真共有サービスで自前でリサイズを書いていたので嬉しい
- https://sphotz.jp/
- 退会時のユーザー全削除、画像リサイズ、自動翻訳、メール配信など……
- ソースコードは全て GitHub にて公開中
IaC と Firebase
- Firebase(特に Functions)は強制的に IaC 化されるのが良い
- アプリケーションコード = クラウドインフラになる
- 小規模のチームでありがちな GUI でポチポチしてできたインフラの使い回しにならない
- 個人や少人数で CloudFormation や Terraform を完全にメンテしきれるわけではない
- AWS や GCP だとできることが豊富すぎるけれど、Firebase は機能が少ないからこそできている
- Firebase を使う以上インフラ構成は大体おなじになるため