UIT INSIDE

LINE UIT室の開発者による「最新のフロントエンド」をキャッチアップできる Podcast

  • オープニング
    00:00
  • 1. Oliver 自己紹介
    00:50
  • 2. みんなの Firebase 利用状況
    01:17
  • 3. Firebase の便利なところと使いかた
    04:56
  • 4. Firestore のルール、困ってる?
    14:15
  • 5. Firebase のプランと課金額
    20:29
  • 6. Extensions 期待の機能
    27:01
  • 7. IaC を強要される世界の嬉しさ
    32:10
  • 8. 個人開発者からみた Firebase
    35:45
  • 9. クロージング
    38:10

ep.24 Firebase for Indies Web-App Developers

2019/10/04
467 views
HANATANI Takuma緑豆はるさめおりばー

@potato4d と @spring_raining が、個人開発者の @oliver_diary と共に小規模チームにおける Firebase、Firebase を使って嬉しかったこと、Firestore のルールのつらさ、Extensions、IaC について語りました。

ゲスト紹介

最近の 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 で処理
  • spring_raining は DeepGlyph にて利用中
    • Firestore 以外だいたい使ってる
  • おりばーも最近 Firebase で使うことが多くなっている
    • 元々 Ruby on Rails でサービスを作ることが多かった
      • 最近は便利じゃんとなって使うことが増加
        • Rails のつらさと戦うことも多かった
    • 新規プロダクトでも Firebase 利用中
      • spring_raining と共に開発中
      • Twitter API と連携する形で Firebase を全力で活用
        • Functions で定期的な Twitter API へのアクセス
        • Twitter API のアクセス結果は Firestore に格納
      • Firestore との連携を考慮した Functions も活用中
        • いいねボタンを押したときにデータを反映する処理

Firestore のルールについて

  • Firestore のルールどうしてるか
    • Firestore のルールでアプリケーションのパターンは網羅できる
      • 如何に大変さを許容するか?が論点に
    • どこまで Functions で守るか
      • Read だけ Firebase SDK、Write は Firestore
        • Pros: 安全、Readでリアルタイム性は担保できる
        • Cons: コールドスタートが辛いのとパフォーマンスが良くはない
      • 基本全部 Firestore
        • Pros: 真価を発揮できる
        • Cons: 少しのミスが致命傷に成りうる
      • ユーザーのネームスペース上だけ Firestore で Shared は Functions
        • Pros: 基本はハイパフォーマンスかつ安全、いいね数のようなSharedは遅延と結果整合を許容できる
        • Cons: 設計の塩梅が難しい
  • Firestore のルールを書くエディタについて

Firebase のプランについて

  • プランの話
    • みんなプランどうしてる?
      • おりばーは Spark や Frame が多く、最近 Blaze もたびたび利用
        • Spark で済むなら Spark にして Frame も利用。最近は Blaze も増加
      • potato4d と spring_raining は初手 Blaze がほとんど
        • 人気が出なければ 25 ドルもかからないし出たら収益でペイするスタイル
      • 共通してそもそも安いのであんまり気にしてない
    • どういうときに課金にするか
      • Functions から Outgoing の通信をするとき
      • そもそも書き込み量が予想されるとき
      • 学生時代はそもそも課金が壁
      • クレカ登録したくない話
    • ちなみに……
      • UIT meetup vol.7 で行った「いいね」システムは 100k R / 30k W で 50 円程度
      • おりばーが最近個人プロダクトで 240k R をしたときで 10 円単位

Extensions への期待

IaC と Firebase

  • Firebase(特に Functions)は強制的に IaC 化されるのが良い
    • アプリケーションコード = クラウドインフラになる
    • 小規模のチームでありがちな GUI でポチポチしてできたインフラの使い回しにならない
      • 個人や少人数で CloudFormation や Terraform を完全にメンテしきれるわけではない
    • AWS や GCP だとできることが豊富すぎるけれど、Firebase は機能が少ないからこそできている
      • Firebase を使う以上インフラ構成は大体おなじになるため

BGM & SE: 魔王魂