僕のYak Shavingは終わらない

車輪の再発明をやめたらそこには壮大なYakの群れが

『iOSアプリ開発者のためのFirebase入門』を読んだ。

booth.pm

本の感想としては、ざっくりドキュメントから読むのがしんどい人用に掻い摘んで要点をまとめてくれているので、実装部分を読まなくても全体を把握するのに適してるなってのと、筆者の個人的なまとめ(Realtime DatabaseとFirestoreどっちがいいの?みたいな)があるので、第三者のコメントを見て思考をショートカットできたのが良かったです。

Firebaseについては、

  • Google傘下に入ったのでClashlyticsやFabricを個別に導入して移行を繰り返してきた身としては、「やっと決着(終着)したか?」とアプリの解析ツールとして最後の希望みたいな印象を持っている
  • AWSのS3やLambda、DynamoDB、Cognito等のいいとこ取りをして一つのパッケージ(サービス)にしているのが、「もうFirebaseのことを考えていればいいんだ」って心の平穏を保てそう

という感じで良い(疲れているのか??)。

Firebaseざっくり

  • 解析ツール全部のせ(クラッシュ分析、コホート分析、アクティブ分析等諸々GAにあるようなやつも)
  • アプリのプッシュ通知部分を肩代わり
  • 認証系実装の肩代わり(TwitterFacebookGoogle,SMS認証、普通のID認証、匿名認証など、開発初期でめんどいけど入れておきたい系)
  • リアルタイムデータベース(いわゆるKVSだけど、データをアプリローカルでキャッシュしつつ、ネット上で変更があったらリアルタイムに反映などの基盤も提供)
  • 更に上記の進化版でよりRDB的にSQLも書けるデータベース(ベータ)
  • S3的なストレージ、ホスティングもできる(Reactとか静的サイトをぽんと置ける、認証ユーザーのみのアクセス許可等も可能なはず)
  • デプロイなしでのアプリ設定変更(configファイルをWebコーンソールから編集して条件フィルタして反映、A/Bテストなどを考慮)
  • AWS Lambda的な感じでイベント拾って任意のソースコードを実行
  • etc…

AWSでもほぼ同系統のことができるけど、Firebaseは一気通貫でできるので、色々コストは減りそう。 ただ、すでにAWSを導入している場合には併用することの弊害があると思うので、その辺は責務を競合しないように決めをつくっておく必要あり。

導入の簡単順としては、解析系→通知系→認証系→(必要なら)DB・FaaSでゴニョゴニョという感じですかね。

最後に行くほど、やるときに適切な設計が必要な気がします。

次はこの本を読みます。

booth.pm