自分を攻略していく記録

自分がやりたいことを達成するには何をすればいいのか、その攻略していく過程をつらつらと

Firebase Meetup #4に行ってきました

firebase-community.connpass.com

Firebase Meetup #4に行ってきた。BLOG枠での参加。なかなか盛り上がっていた。

他のBLOG枠のsu-さんの記事はこちら。

tech-blog.sgr-ksmt.org

Firestoreのセキュリティルールについて (Web) @k2wanko

speakerdeck.com

Firebase利用企業の62%がDBのセキュリティルールにミスがあり機密情報が公開されている。その中でセキュリティルール周りの知見の共有だった。

Realtime Database(以下RTDB)、Firestore、Storageでセキュリティルールという概念が出てくる。

  • RTDB
    • ゲームやチャットに向いてる
    • jsonでセキュリティルールを書いていく
    • 条件式を書いていくこともできる
    • 上層でマッチすると、下層で上書きしても反映されない。上の階層のほうがoverrideしてしまう
    • これらはjsonやらないといけない
    • コメントかけない
    • 関数がない
    • 型がない
    • ハイライトがない
    • 落ちていることがちょいちょいある

みたいな雑感。

Boltを使うと、RTDB用のjsonを吐き出してくれるし、TypeScriptのような型定義で便利。ただ、完全に信じるのは危険かも...。

github.com

  • Cloud Strorage

    • 画像とか動画とか大きめのデータ用
    • jsonではなく独自言語でかける
    • GCSのアクセス制御と同期しない
    • resource.data.visibility == 'publicだとread: if flase;でもURL経由で読み取れてしまう
    • ACLをちゃんと見よう
  • Firestore

    • RTDBの次世代のドキュメント志向のDB
    • backendはspannerなので安定性はある
    • jsonではなく独自言語でかける
    • セキュリティルールとindexが別
    • IAMの設定もできる
    • ワイルドカードを除いて、下階層に権限は影響していかない
    • get()やexists()は呼び出し回数に制限やreadのコストがかかる
    • まだベータ版だが、スケールアウトがまだ遅いためで、もう破壊的なアップデートはないと言われているらしい
  • protobug-rules-gen

    • protocol bufferの定義から型検査をしてくれる。セキュリティルールを生成するプラグイン

開発時はどうしても後回しにしてしまう部分をしっかり説明されていて、非常に参考になる内容だった。

Firebaseを使ってプッシュ通知基盤を作ったときにハマったところ、よかったところ y.danno

speakerdeck.com

アプリのリニューアル検討、Parseが2017/1/28に終了等の理由によりプッシュ通知基盤をFirebaseに移行した時のお話。

もともとはFirebase Notificationsを利用していたそうだが、送り先はifとかで決めるところがマーケティングチームがやるには厳しい、とかマニュアルではきついといった理由もあり、Firebase Cloud Messaging + αでプッシュ基盤を作成した。

Firebase Notificationsで Topic or FCM?? 問題については遅延なく送信し、届いたかどうかを取得するためにはFCMでやる必要があったそう。FCMトークンの管理そのものをどうするか、という問題もあり苦労したとのこと。Firestoreでお気に入りしたかどうかの情報を保持してそれをもとにプッシュの送信先を決めるようにしている。

プッシュ送信にはAppEngineを利用し、20万件ずつ送ったがいい感じにスケールアウトしてくれたのも良かったということだった。

今後はWeb Pushやリコメンド、緊急速報、ライブ動画のコメントあたりをFirebaseを使って解決していきたいという話だった。

Growth product @1amageek

なんで今からFirebaseなの、というテーマでの発表。

Internet普及率がここ20年強で9.2%から83.5%になっており、その間、AWSGCPのAppengineなどは、Scaleを支えるサービスを作ってきた。今後は新しいサービスを作る時代だ、ということ。

プロダクトとはコンテンツ であり、コンテンツのIN/OUTの最適化がうまくできているかどうかが重要になってくる。エンジニアリングとマーケティングはそこのIN/OUTのPDCAの高速化が求められる。

Firebaseの開発速度は破壊的でそれをライブコーディングで実演された。

インスタみたいに画像をライブラリから選択してアップロードするDEMOアプリを見せてくれたが、Xcodeソースコードを開くと、おもむろに利用しているViewControllerとかStoryboardを削除しはじめる @1amageek さん。そして、5分たらずでFileのアップロードやデータの取得、その描画をライブで実装していた。とにかく早い。AWSや既存のREST APIを作るスタイルであれば一人で半日はかかると思われるコードもものの数分だった。

github.com

Firebaseは作っては壊す、に非常に向いている とのこと。

Quickstart-android/MLKitについて @yamacraft

speakerdeck.com

MLKitを動かすために公式サンプルが行っていることの解説をされていた。

  • カメラの制御
  • onPreviewFrameでプレビュー画面のBufferをFirebaseVisionFaceDetectorに流し込み
  • その結果をもとにプレビュー画面に結果をオーバーレイ

MLKitの部分は簡単だが、サンプルコードのほとんどがカメラの制御になっている...!!カメラのデータをVision APIに送り続けるとか、受け取ったデータをプレビューに表示し続けるのが結構手強いらしい。

Firebase Authenticationで色々使ってみた @teyosh

f:id:ngo275:20180703002912p:plain:w500

  • ユーザ管理は以下のようにプロパティがある

    • uid
    • display name
    • email
    • phoneNumber
    • photoURL
  • 対応プロバイダ・方式は以下の通り。

loginしたuserとcredentialのヒモ付が簡単で user.linkAndRetrieveData(with: credential) でいける。メールの更新等も user.reauthenticateAndRetrieveData(with: credential) でいける。

Firestoreをもっと手軽に使えるfirestore-simpleを作った @Kesin11

speakerdeck.com

APIが言語によらずだいたい同じだが、汎用化してライブラリ作ったほうがもっと気持ちよくかけるよね、という動機でライブラリを作られたそう。

以下のようなツラミが開発していてあったそう。

  • 素のFirestoreは毎回コレクションへのパスを書くのはめんどくさいので、自分でコレクションごとのモデルを作るか
  • FirestoreではQuerySnapshotで返ってきてArrayではないからメンドくさいから、いい感じにArrayで扱えるようにするか

Cloud Functionsとかはネイティブアプリエンジニアでも利用することはあるので、ぜひ触ってみたいと思った。

まとめ

Firebaseの盛り上がりを感じた。結構iOSAndroidのクライアントのエンジニアが多かった印象。Firestoreを触っている人が多く、いかに大きなインパクトを与えているのかを再認識した。

先週末にFirestore・Pringを使った記事も上げたのでぜひ参考に!

diary.shuichi.tech

次回はLTする予定なのでよろしくお願いします!

firebase-community.connpass.com