開発合宿で作成したシステムです。 Firebaseの使い心地の検証の目的で作成しました。
ねこかんねこかんFirebaseを活用した猫監視システムFirebaseを活用した猫監視システムreireias1
View Slide
モチベーションモチベーションFirebaseがWebアプリ用のインフラとしてどの程度使えるか知りたかった不在中の猫が家で何しているのか気になる2
できたもの(PWA版)できたもの(PWA版)3 . 1
できたもの(Web版)できたもの(Web版)3 . 2
ソースコードソースコードreireias/cat-watcherreireias/raspberrypi-ansible3 . 3
採用技術採用技術4 . 1
RaspberryPi ZeroRaspberryPi Zero512MB RAM, 802.11b/g/nカメラモジュールモバイルバッテリーからの供給での稼働を想定4 . 2
Vue.js + Vuetify.js + Nuxt.jsVue.js + Vuetify.js + Nuxt.js(個人的に)鉄板の組み合わせVuetify.jsのUIコンポーネントNuxt.jsによるSPA、PWANuxt.jsが内包するVuexによるFluxでのデータ管理4 . 3
FirebaseFirebasemBaaS(modile Backend as a Service)Authentication: 認証Hosting: 静的サイトホスティングFirestore: リアルタイムNoSQLStorage: データ保存ストレージFunctions: イベント駆動形FaaSMessaging: Push通知4 . 4
システム構成システム構成5 . 1
処理フロー(画像追加)処理フロー(画像追加)1. コマンドが動体を検知し、画像を保存2. shellスクリプトが画像の追加を検知し、 コマンドでCloud Storage for Firebaseにアップロード3. FunctionsがStorageへのファイル追加をトリガーに起動Cloud Vision APIで画像にラベル付けCat が含まれていれば、DL URLを発行し、Firestoreにデータ登録含まれていなければ、画像を削除する5 . 2
4. Firestoreへのデータ追加をトリガーに、Functionsが起動MessagigでCatトピックを購読しているデバイスにpush通知送信5. クライアントはHostingされた静的サイトへアクセス6. AuthenticationによるGoogle認証連携7. クライアントからFirestoreに接続し、画像一覧のデータを取得8. データ中のDL URLでStorageから画像を取得5 . 3
処理フロー(ユーザー登録)処理フロー(ユーザー登録)1. Google認証でログインしたイベントをトリガーにFunctionsが起動ユーザーのデータをFirestoreに追加する2. 通知ONボタンをユーザーがクリックブラウザの通知の許可を利用し、許可された場合registerTokenが発行される発行されたregisterTokenをFIrestore上のユーザーデータの属性にセット5 . 4
3. Firestoreのユーザーデータの更新をトリガーにFunctionsが起動registerTokenが更新されていた場合は、それで をsubscribeするregisterTokenのみでも個々にメッセージを送ることができるが、最大で同時に100通が上限Topicに対する配信なら上限は無制限5 . 5
Firebaseに対する考察Firebaseに対する考察6 . 1
WebアプリエンジニアWebアプリエンジニア(サーバーサイド/フロントエンド)として(サーバーサイド/フロントエンド)として認証連携周りがかなり楽。革命レベル。デプロイが簡単Storage/Firestoreのアクセス権が簡単に定義できるFunctionsをWebエンジニアだけで簡単に実装/デプロイPush通知機能があるNoSQLの設計と、Functionsによるイベント駆動のサーバーサイド設計の難易度が高い全てNoSQLのFirestoreで実現できるわけではない6 . 2
SREとしてSREとして圧倒的にフルマネージド = 管理コスト低証明書管理不要スケーリング(Functions/Firestore/Hosting)もろもろのサーバーの管理コスト無しGCPとの統合が容易足りない機能はGCPでまかなうことができる親和性というのは大事、親和性が低いと権限管理がうまくいかない6 . 3
Firebaseの個々の機能に関してFirebaseの個々の機能に関して7 . 1
AuthenticationAuthenticationfirebase-uiを使うと超低コストで3rdPatyログインのボタン+機能が実現可能ただし、リダイレクト時のこまかい挙動に関して手を入れれないのは微妙BtoB向けのような、ユーザー管理者によるユーザー管理機能の提供は難易度高そう運用者によるユーザー管理画面はAdmin SDK + Serverでいけそう7 . 2
HostingHostingCDN、証明書、HTTP2対応等が簡単に実現できる静的サイトがメイン(or Mobileアプリ)の場合はこれで十分7 . 3
StorageStorage複雑なアクセス権制御さえなければ十分裏はGoogle Cloud Storageなので、S3と同等と思ってよいです7 . 4
FirestoreFirestoreFirebaseを使いこなせるかは、Firestoreを使いこなせるかにかかっていると言っても過言ではないリアルタイムNoSQL(マジでクライアントにリアルタイムに変更が伝わるので、UXが良い)NoSQLの一般的な特徴になるが、複雑なジョイン、複雑な検索、複雑なリレーショナルは苦手それと引き換えにパフォーマンスとスケーラビリティが高いこれらの特性から従来のRDBMSとは異なる設計を求められる点が難しい7 . 5
FunctionsFunctionsFirebaseのバックエンドがGCPなので、いい感じに統合されているGCPのAPI(今回はVision API)がAPIキー等なしで簡単に利用できるデバッグをローカルでできる機能があるが、試せていない7 . 6
MessagingMessagingPush通知がまあまあ簡単にできる認証キーとかトークンの関係で、意外とサーバーサイド(Functions)上でしかできない(クライアント側でやると面倒な)ことがあったりするトピックの購読による配信は複数のトピックを組み合わせられるので、これで基本はいろんな配信パターンを実現できるはず7 . 7
結論結論Firebaseの機能で満たせる要件の場合、圧倒的に開発コストを抑えることが可能NoSQLで足りるか?Functionsの制約下でバックエンドは十分か?上記の見極めは難しい開発初期に見通せるか?最初からRailsありきと、(Firebaseで作って)途中でRails等を足すのとどちらがコストが低いか8
その他感想1その他感想1やはりベースはmBaaSであり、モバイルでしか利用できない機能のほうが多いFirebaseのAPIリファレンスサイトがちょっと重いfunctionsの名前をイベント名ベースにするのか、処理内容にするのか悩むPWAのservice workerのデバッグめっちゃ辛い9 . 1
その他感想2その他感想2参考になったpush通知をクリックした際、PWAで開くのか、ブラウザで開くのかはユーザーの設定次第firebase-uiは簡単にログインボタンを出せるが、リダイレクト時のロードをアニメで制御するのが難しいiOSのPWAでのリダイレクトを伴うGoogle認証が、最新のOSでないと成功しない(iOSのPWA対応が遅い)ここ9 . 2
その他感想3その他感想3ステージング環境が勝手に作成される(まだ試せていない)USB-OTGむずい9 . 3