#FJUG #firebase Firebaseの知見を共有する Firebase Meetup #7 @mercari に参加してきたまとめ

firebaseについてナレッジを共有するイベントFirebase Meetup #7 @mercariがメルカリで行われたので意気揚々とナレッジを吸収しにいきました。
これはそんなfirebase信者によるまとめ。

QAシステムをfirestoreで作ったお話

• google slidesというサービスがあり、merpayの中でもQAシステムとして使っていたが、次第に用途に合わなくなったので作ってみた
• デモサイト
• 要件
  • 社内のGoogleアカウントのみで書き込めるようにしたい
  • リアルタイムに反映させたい
• gsuite限定にするというのがやったことなかった
  • セキュリティルールでカバーした
  • request.auth.token.email.matches(*@mericari[.]com)
• 2hぐらいで作ったが、他の勇者からPRもとんで見た目が良くなり、気づいたらメルカリもつかっていた
• 問題
  • 順番が変わって欲しくない時にリアルタイムが故に順番が変わってしまうというfirestoreならではの問題が発生する
• QAシステムに追加したいもの
  • スマフォでみやすくしたい
  • 翻訳機能

パネルディスカッション

• @guiltymorishita様
  • gincoのCTO
  • すべてGCPとfirebaseで動いている
• @_mono様
  • 二人で匿名チャットアプリ作ってます

きっかけ

• アーキテクチャを考えるときに、スケーリングを考えて技術を選定していた（@guiltymorishita様）
  • ブロックチェーンではユーザがリロードを繰り返さないとconfirmを確認できない
  • confirmが起こったときにサーバ側でpush通知を送って更新しようとしていたが、それがfirestoreだった
  • 非常に簡単に使えて、getter/setterのAPIを作る必要がないので、クライアントからDBがいじれる事がわかってfirebaseで作った
  • リリースの直前に使いづらいとなって、調べて2週間くらいで作り変えて、APIが2つだけになった
  • 何のAPIが残ったのか？
    • カスタムユーザの認証のAPIと、ユーザがいるのかどうかのAPIだけ残った
    • firebaseのカスタムユーザはサーバで認証させたことに対してログインさせるという方式があるが、gincoの場合、ブロックチェーンの仕組みを使ってログインさせようと思ったので、カスタムユーザログインを使って実装した
• firebaseは2015年から触っている（@_mono様）
  • 下地がしっかりしているので信頼できる
  • 11月くらいからfirestoreのbetaがリリースされて使ってみたらしっくりきた
  • いろいろ書き換えたら全部書き換わっていた
• ルールのテストはどうしてるか？
  • あんまりしてない（@_mono様）
  • cookpadのブログに記事があります

firestoreを使って最初の印象はどうだったか？

• Googleが提供してるSDKが充実していて直感的に使える（@guiltymorishita様）
  • 即データが取れる
• Nosql dbを使ったことなかったが、なれれば快適に使えそう（@_mono様）
  • Firebase realtime dbは扱いが難しそうだが、jsonツリーなどの懸念事項がかなりクリアされている

いいとおもったところは？

• リアルタイムでクライアントとDBが同期される（@guiltymorishita様）
  • 直接DBの操作ができるので、クライアントのエンジニアがDBの開発をできるので、開発速度が段違い
• mysqlで組もうとしていたので対比すると、自前でRDBでもっていたのは大変で時間がかかるが、firestoreはローカルdbに保存するような感覚で使えて、オフラインでも使えるので使いやすい（@_mono様）
  • 勝手にスケーリング性能がついてくるので安心感がもてる

不安だったところは？

• 導入だったのがbetaだったのが不安（@guiltymorishita様）
  • Googleのサービスのbeta版は破壊的変更がないのでとりあえず使ってる
  • Webに情報があまりない
• nosqlを使ったことがなかったのと、DBとクライアントの接続型がうまく扱えるのかが不安だった（@_mono様）

料金はどれくらいかかってるか？

• ブロックチェーンのデータを監視してGETしてるので、function含めて20万円くらい（@guiltymorishita様）
  • ユーザ数は35,000人
• 1dauで0.5円~1円くらい（@_mono様）

テストはどうしてるか？

• セキュリティルールをしっかり書きましょう

セキュリティルールを書かなかったらどういう問題が起こるか？

• 脆弱性にさらされます
• ex: 「Firebaseの脆弱性で1億件超漏洩」の真相とは？ #Firebase #FJUG
• ex: 合計1億件以上の個人情報がFirebaseの脆弱性によって公開状態に

不安解消されたか？

• 潰れることはないと思うので大丈夫だと思ってる（@guiltymorishita様）
  • どんどん使いやすくなっている
  • 不満は今のところないが、導入のところでKVSになれないと難しいかも
• firebasのドキュメントちゃんとよんでいじった（@_mono様）
  • Twitterやblog、youtubeなどで発信がされていて、日々目を通しておくと技術的不満はなくなる
• youtubeは結構ウォッチしておいたほうがいい（@guiltymorishita様）
  • firestoreやfunctionをこう使うといいよと説明してくれるのでとてもよい

今の仕事との相性はどうか？

• ブロックチェーンの情報をストアするときにはよい （@guiltymorishita様)
  • stateが変わって通知するときにはベスト
• チャットアプリなので相性がいい（@_mono様）
  • 定期的実行をやるときはfirebaseだけではすまなくて、GAEや外部サービスをつかわないといけない
  • しかし最近cloud schedulerがbetaでで始めたのでそれが使えれば楽になると思う
    • CloudScheduler: 今までGAEじゃなくてもcronの定期実行のためにGAEを設定しないといけなかったのが、cronの機能だけ切り出されたサーバレスサービスです
    • バッチ処理もできます
  • どのタイミングで使っているか？
    • チャットの自動返信やバックアップに使っている(@_mono様)
    • バックアップは毎朝やっているが、1日の数割のコストが掛かっている
• betaになって使っているが、firestoreのバックアップをcloud schedulerに置き換わってとてもシンプルになった（@guiltymorishita様)
• CloudSchedulerは使えるんでしたっけ？
  • betaが出たので一般的に使える
• Firebase storageのバックアップはどうしているか？
  • やっていない（@_mono様）
  • storageはほとんどやっていない（@guiltymorishita様)

お気に入りの機能はなんですか？

• CloudFunction for firebase（@guiltymorishita様)
  • firebaseの大体の機能と連携していてトリガーでfunction実行できるのでやりたいことをCloudFunctionでできる
    • クライアントでやっていためんどくさいことをcloudfunctionでできる
• Authentification, firestore, cloudfunction（@_mono様）
  • 大抵のサービスで必要で手間がかかるものだが、高品質で低コストで使えるのでとてもいい

追加して欲しい機能は？

• firestoreのローカルで実行できる環境がほしい（@guiltymorishita様)
  • 1プロジェクトで1つしか使えない
  • 複数人でやろうとするとコンフリクトがおきてしまう
  • 1project1ユーザでやるというのもみたが、それも非常にめんどくさい
  • メンバー大きくなったらdatastoreのローカルエミュレータがほしい
• いくつか候補には上がっていた (cf: Firestoreの公式要望アンケート ) （@_mono様）
  • 今firestoreでクエリできるが、RDBみたいなsumやcountなどもほしい
  • 全文検索も検討としてあげられているが、algoliaという全文検索サービスを使えと公式ではいっている
  • subcollectionの横断的なクエリもほしい
    • subcollectionはデータ構造分離できて便利だが、横断的に検索したい
  • 定期バックアップも候補に入っていた
  • 最近ワン・コマンドでバックアップできるようサポートされたが、マネージドなサービスがほしい
  • aggregateな関数はもしかしたら発表されるかも？（ファシリテータ）

全文検索をしたい場合firebaseだけで作れないか？

• 無理です。elasticsearchか、algoliaを使ってください（ファシリテータ）
• algoliaは高いが、手間はかからない（@_mono様）

これから使う人におすすめの言葉

• 本当に簡単なのでぜひ使ってみてください（@guiltymorishita様)
• firebaseは優れたサービスだったが、firestoreが出てきてかなり強力で使わないとかなり損です。（@_mono様）
  • 新規に作るなら考慮したほうがいい

Firebase Cloud Messagingで通知の配信遅延と戦ってみた

call.jpというサービスでのお話

サービス概要

• スマホで人を呼び出せるサービス

利用シーン

• カフェで店員を呼ぶときにスマフォでQRを読み込むと店員が呼べる
  • 高田馬場の10℃カフェで試験運用中
• 勉強会などで、座席表と名前を入れてボタンを押すとチュータがくる
  • ジーズアカデミーにて試験運用中

どのようにfirebaseを使われているか

• Realtime dbとCloudFunctionsを使ってflutterでアプリを作って通知を出す

FCMの配信遅延

• アプリに通知に30秒くらい通知に時間がかかることがある
• 配信遅延を計測してみた
  • CloudFunctionsからテスト用のエンドポイントを叩いて、配信がされるまでの時間を測定
  • ios, wifi, backgroundのアプリの状態で計測してみた

FCMのメッセージ配信方法について

• 端末トークン
  • fcmに登録されているのでそれに紐付いて配信する
  • 1:1で配信する
• 端末グループ
  • 端末のグループをfirebaseのapiにて作成して配信する
• topic
  • 自由にtopicと呼ばれるグループにsubscribeして配信する
• 結果: ほぼ有意差はなし

FCMのメッセージタイプ

• 通知メッセージ
  • notificationのtitle, bodyをいれると通知が表示される
• データメッセージ
  • Ios,androidでわけて表示できたりする
  • しかし、topicでの配信は利用できない
  • Iosはapnsにいれて配信する
• 結果: 気持ち、データメッセージのほうが少々早かった

CloudFunctionsのリージョン

• デフォルトだとus-centralだが、東京リージョンも使える
• USリージョンと比べたが、ほぼ変わらないが、東京のほうがむしろ遅い

考察

• しばらく間をあけてテストを行うと7~8秒の遅延があるので、立ち上げに時間がかかっているのでは？

結論

• 1:1などの状況下では配信方法、メッセージタイプ、リージョンは影響しない

今後

• Flutter vs native
• Ios vs android
• Firebase realtime database

firebaseで作ってつらかったことなどの共有

firebase開発から2ヶ月で取り組んだことについて

UI周り

• vue.js + firebase + typescriptで作った
• Vue.jsは学習コストが少なくて作れる
• Elementui
  • それっぽく作れる
  • しかしデスクトップ向けなので飛ばした
• Vuesax
  • Componentライブラリだが、最近勢いが会っていいが、ボトムアップでレイアウトレベルのデザインやるのが難しい
  • ページ単位でのサンプルが全然ない
• Vuetify
  • マテリアルデザインガイドに作られてる
  • マニュアルでサンプルがあるが、コピペだけで動かせる
  • 30分くらいで1個の画面つくれちゃう
  • SPAで最初は作りたかった
• vue-auto-routing
  • ktsnさんはコミッターなので使ってみたらとてもうまく作れた

firebase

• firebaseアプリのライフサイクル
  • ファーストアクセス時にローディングするのかと思った
  • ページアクセス時に認証は時間がかかる
  • Firebase consoleとかも最初はローディング画面
• 認証するとユーザkeyがとれるので、そのkeyをつかって情報がとれる
  • profileEntityがあったとき、userIdが外部キーを持っていた場合、documentにuseridを含めたほうがいいのかな？
• 今までの開発経験を活かせるように関数でできた
• loginWithLocalCacheでキャッシュを使ってログインして失敗したらログインするようにしている

型の悩み

• interfaceを定義した
  • インターフェースに依存するのはアーキテクトの観点からもとてもいい
• ドキュメントのread writeはドキュメント単位
  • 見せてはいけない情報はどうするか？→権限別にコレクションを分ける
• PublicUserの更新タイミングはCloudFunctionで書く
  • privateユーザがset/updateされたタイミングでprofile更新したらpublicuserを更新するようにした

まとめ

• カルチャーショックや学習コスト、ベストプラクティスがわからない
• 学習コストはかかったがそれでも圧倒的に早かった
• read単位で課金が発生するので、チャット一覧についてreferenceを埋め込むのかユーザ名を埋め込むのかなどコストを下げる方法があるが、なれてないことを考えると開発が遅くなるので、最初はuserIdをつっこんで読み取ればいい。
  • あとで学習してから修正すればいい

@mogmetの所感

今回もとても参考になる情報がいろいろと出てきました。
個人的によかったのは、以下です

• 全文検索はalgoliaでやる（リードはし放題らしい）
• firebaseの初回認証は時間がかかるのでキャッシュしてしまう

特に初回認証をキャッシュしてしまうのはなるほどと思い、いつも初期ロードが長くていつも悩まされていたので是非オフラインキャッシュの恩恵をうまく使おうと思いました。

最後に、おしゃれハンバーグがとても美味しかったです。