Firebase9へ移行してみた。つまづいた点を公開
はじめに
個人開発しているSushi WorkというWEBサービスをFirebase8から9に移行した時のメモです。これから移行する人のお役に立てば幸いです。
移行を完了させてみて思うのは、1番の大敵は、移行面倒だなー、デグレしたらやだなーという気持ちです。やってみると、Firestoreのクエリ書き換えに時間はかかるけど、そんなに難しくないので、さくっと終わらせてしまいましょう！
前提
基本はここに書いてあります。
公式よりざっくり知りたい方はこちら。
移行前のサイズを知る
Firebase9にする1番のメリットは、Firebaseライブラリのバンドルサイズの削減です。どれくらい削減できたかを知るために、移行前のサイズを調べておきましょう。
を使います。Vue cliを使っていれば特にインストールせずに使えます。
npx vue-cli-service build --report
を実行すると、dist/report.html が作成されるので、 open dist/report.html
で開けます。
FirebaseUIは、compat版だけに対応
FirebaseUIは、v6.0.0で、Firebase9のcompat版だけに対応してます。
そのため、FirebaseUIを使っていると、サービスをFirebase9のmodular版に対応させても、バンドルサイズ削減の恩恵に預かれません😭
自分のサービスは、FirebaseUIを使っていたため、バンドルサイズはgzippedで12KBしか削減できませんでした。
まだmodular版に対応させる目処が立ってないようなので、気長に対応を待つか、FirebaseUIを外す必要がありそうです。
手順
- とりあえずcompat版で動くか確認
- 簡単にできるものから書き換える。Firebase Auth、Functions、Analyticsなど
- 時間がかかるものを書き換える。Storage、Firestoreなど
- initializeAppを書き換える。
自分の場合はFirestoreのクエリ書き換えに全体の8割の時間がかかりました。
公式ドキュメントにFirebase9とFirebase8の書き方が両方載ってるので、それを見比べながら修正していきます。
例
リファレンスも役立ちました。
Firestoreでの注意点
existsがプロパティからメソッドに変更されている
この記事を見ていたので、事前に気付けました。他にもこういう罠がないか不安になリます。
2022/02/21 追記
公式ドキュメントにも本件が追加されていました。
サブコレクションの取得
クエリ書き換えをしていると、最初はこのクエリ、どう書き換えるんだろうと悩みます。例えば、サブコレクションの取得は、どうすればいいのか戸惑いました。
何度も書き換えていると、段々理解できます。最初はとっつきにくいですが、徐々にこっちの書き方のが良い面もあるなと思えてきます。
オフラインモード
オフラインモードを有効化するコードの書き換えです。
firestore
.enablePersistence({
synchronizeTabs: true,
})
.catch(function(err) {
if (err.code == "unimplemented") {
console.log("Offline support error.");
}
});
enableMultiTabIndexedDbPersistence(db).catch(function(err) {
if (err.code == "unimplemented") {
console.log("Offline support error.");
}
});
Firebase9では、 enableIndexedDbPersistence と enableMultiTabIndexedDbPersistence の2つのメソッドが用意されていました。
複数のタブで同一のIndexedDBを使用したいので、enableMultiTabIndexedDbPersistence を使っています。
Admin SDKもmodular対応が必要だよ
こちらはまだ対応してないので、後でやる予定。
終わりに
こういう気が重くなる作業は、まず少しでも着手して、やる気を上げるのが重要だなーと感じました。
Discussion