[開発合宿] Firebase + Nuxt.js + RaspberryPiによる猫監視システム / Cat Watcher

開発合宿で作成したシステムです。
Firebaseの使い心地の検証の目的で作成しました。

Transcript

1. ねこかん
   ねこかん
   Firebaseを活用した猫監視システム
   Firebaseを活用した猫監視システム
   reireias
   1
   

   View Slide

2. モチベーション
   モチベーション
   FirebaseがWebアプリ用のインフラとしてどの程度使え
   るか知りたかった
   不在中の猫が家で何しているのか気になる
   2
   

   View Slide

3. できたもの(PWA版)
   できたもの(PWA版)
   3 . 1
   

   View Slide

4. できたもの(Web版)
   できたもの(Web版)
   3 . 2
   

   View Slide

5. ソースコード
   ソースコード
   reireias/cat-watcher
   reireias/raspberrypi-ansible
   3 . 3
   

   View Slide

6. 採用技術
   採用技術
   4 . 1
   

   View Slide

7. RaspberryPi Zero
   RaspberryPi Zero
   512MB RAM, 802.11b/g/n
   カメラモジュール
   モバイルバッテリーからの供給での稼働を想定
   4 . 2
   

   View Slide

8. Vue.js + Vuetify.js + Nuxt.js
   Vue.js + Vuetify.js + Nuxt.js
   (個人的に)鉄板の組み合わせ
   Vuetify.jsのUIコンポーネント
   Nuxt.jsによるSPA、PWA
   Nuxt.jsが内包するVuexによるFluxでのデータ管理
   4 . 3
   

   View Slide

9. Firebase
   Firebase
   mBaaS(modile Backend as a Service)
   Authentication: 認証
   Hosting: 静的サイトホスティング
   Firestore: リアルタイムNoSQL
   Storage: データ保存ストレージ
   Functions: イベント駆動形FaaS
   Messaging: Push通知
   4 . 4
   

   View Slide

10. システム構成
    システム構成
    5 . 1
    

    View Slide

11. 処理フロー(画像追加)
    処理フロー(画像追加)
    1. コマンドが動体を検知し、画像を保存
    2. shellスクリプトが画像の追加を検知し、 コマンド
    でCloud Storage for Firebaseにアップロード
    3. FunctionsがStorageへのファイル追加をトリガーに起動
    Cloud Vision APIで画像にラベル付け
    Cat が含まれていれば、DL URLを発行し、Firestore
    にデータ登録
    含まれていなければ、画像を削除する
    5 . 2
    

    View Slide

12. 4. Firestoreへのデータ追加をトリガーに、Functionsが起動
    MessagigでCatトピックを購読しているデバイスに
    push通知送信
    5. クライアントはHostingされた静的サイトへアクセス
    6. AuthenticationによるGoogle認証連携
    7. クライアントからFirestoreに接続し、画像一覧のデータ
    を取得
    8. データ中のDL URLでStorageから画像を取得
    5 . 3
    

    View Slide

13. 処理フロー(ユーザー登録)
    処理フロー(ユーザー登録)
    1. Google認証でログインしたイベントをトリガーに
    Functionsが起動
    ユーザーのデータをFirestoreに追加する
    2. 通知ONボタンをユーザーがクリック
    ブラウザの通知の許可を利用し、許可された場合
    registerTokenが発行される
    発行されたregisterTokenをFIrestore上のユーザーデー
    タの属性にセット
    5 . 4
    

    View Slide

14. 3. Firestoreのユーザーデータの更新をトリガーに
    Functionsが起動
    registerTokenが更新されていた場合は、それ
    で をsubscribeする
    registerTokenのみでも個々にメッセージを送ることがで
    きるが、最大で同時に100通が上限
    Topicに対する配信なら上限は無制限
    5 . 5
    

    View Slide

15. Firebaseに対する考察
    Firebaseに対する考察
    6 . 1
    

    View Slide

16. Webアプリエンジニア
    Webアプリエンジニア
    (サーバーサイド/フロントエンド)として
    (サーバーサイド/フロントエンド)として
    認証連携周りがかなり楽。革命レベル。
    デプロイが簡単
    Storage/Firestoreのアクセス権が簡単に定義できる
    FunctionsをWebエンジニアだけで簡単に実装/デプロイ
    Push通知機能がある
    NoSQLの設計と、Functionsによるイベント駆動のサー
    バーサイド設計の難易度が高い
    全てNoSQLのFirestoreで実現できるわけではない
    6 . 2
    

    View Slide

17. SREとして
    SREとして
    圧倒的にフルマネージド = 管理コスト低
    証明書管理不要
    スケーリング(Functions/Firestore/Hosting)
    もろもろのサーバーの管理コスト無し
    GCPとの統合が容易
    足りない機能はGCPでまかなうことができる
    親和性というのは大事、親和性が低いと権限管理がう
    まくいかない
    6 . 3
    

    View Slide

18. Firebaseの個々の機能に関して
    Firebaseの個々の機能に関して
    7 . 1
    

    View Slide

19. Authentication
    Authentication
    firebase-uiを使うと超低コストで3rdPatyログインのボ
    タン+機能が実現可能
    ただし、リダイレクト時のこまかい挙動に関して手を
    入れれないのは微妙
    BtoB向けのような、ユーザー管理者によるユーザー管理
    機能の提供は難易度高そう
    運用者によるユーザー管理画面はAdmin SDK + Serverで
    いけそう
    7 . 2
    

    View Slide

20. Hosting
    Hosting
    CDN、証明書、HTTP2対応等が簡単に実現できる
    静的サイトがメイン(or Mobileアプリ)の場合はこれで十
    分
    7 . 3
    

    View Slide

21. Storage
    Storage
    複雑なアクセス権制御さえなければ十分
    裏はGoogle Cloud Storageなので、S3と同等と思ってよ
    いです
    7 . 4
    

    View Slide

22. Firestore
    Firestore
    Firebaseを使いこなせるかは、Firestoreを使いこなせる
    かにかかっていると言っても過言ではない
    リアルタイムNoSQL(マジでクライアントにリアルタイム
    に変更が伝わるので、UXが良い)
    NoSQLの一般的な特徴になるが、複雑なジョイン、複雑
    な検索、複雑なリレーショナルは苦手
    それと引き換えにパフォーマンスとスケーラビリティが
    高い
    これらの特性から従来のRDBMSとは異なる設計を求めら
    れる点が難しい
    7 . 5
    

    View Slide

23. Functions
    Functions
    FirebaseのバックエンドがGCPなので、いい感じに統合
    されている
    GCPのAPI(今回はVision API)がAPIキー等なしで簡単に利
    用できる
    デバッグをローカルでできる機能があるが、試せていな
    い
    7 . 6
    

    View Slide

24. Messaging
    Messaging
    Push通知がまあまあ簡単にできる
    認証キーとかトークンの関係で、意外とサーバーサイド
    (Functions)上でしかできない(クライアント側でやると面
    倒な)ことがあったりする
    トピックの購読による配信は複数のトピックを組み合わ
    せられるので、これで基本はいろんな配信パターンを実
    現できるはず
    7 . 7
    

    View Slide

25. 結論
    結論
    Firebaseの機能で満たせる要件の場合、圧倒的に開発コ
    ストを抑えることが可能
    NoSQLで足りるか？
    Functionsの制約下でバックエンドは十分か？
    上記の見極めは難しい
    開発初期に見通せるか？
    最初からRailsありきと、(Firebaseで作って)途中で
    Rails等を足すのとどちらがコストが低いか
    8
    

    View Slide

26. その他感想1
    その他感想1
    やはりベースはmBaaSであり、モバイルでしか利用でき
    ない機能のほうが多い
    FirebaseのAPIリファレンスサイトがちょっと重い
    functionsの名前をイベント名ベースにするのか、処理内
    容にするのか悩む
    PWAのservice workerのデバッグめっちゃ辛い
    9 . 1
    

    View Slide

27. その他感想2
    その他感想2
    参考になった
    push通知をクリックした際、PWAで開くのか、ブラウザ
    で開くのかはユーザーの設定次第
    firebase-uiは簡単にログインボタンを出せるが、リダイ
    レクト時のロードをアニメで制御するのが難しい
    iOSのPWAでのリダイレクトを伴うGoogle認証が、最新
    のOSでないと成功しない(iOSのPWA対応が遅い)
    ここ
    9 . 2
    

    View Slide

28. その他感想3
    その他感想3
    ステージング環境が勝手に作成される(まだ試せていな
    い)
    USB-OTGむずい
    9 . 3
    

    View Slide