背景
名古屋出張で知り合った友人の紹介でGCP・firebase関連の勉強会LTをさせていただく機会をいただくことができ、 以下２イベントにて登壇を行ったのでその内容をブログにも書き留めておこうと思います。
詳細は以下スライドに記載していますが、 AWSを使ったwebアプリ作成方法との比較という形でfirebaseのメリットデメリットをまとめています。
20210326_AWS(S3 Hostingなどなど)からfirebaseに浮気しました
firebaseを使い始めて感じていたメリット・デメリット
メリット
firebaseを使い始めて感じていたメリットは以下の３つになります。 （３つ並べつつ１つ目が全てを含んでしまっています・・・笑）
- 簡単・安くて・便利
- 権限管理がやりやすい
- (おそらく)認証がやりやすい
２つ目の権限管理については人によって分かれており、 ケースによってやりやすい・やりにくいは変わってくるかもしれないです。 ただ僕の場合は「ROLEがADMINとなっている人は＊＊まで見れる」と言った条件を付けたかったので、 AWSのAPI側で頑張るよりかはやりやすいケースが多かったと感じています。
デメリット
firebaseを使っていて感じたデメリット(不便さ)は以下の３つになります。
- firebase functionsで9分以内に終わらない処理の実行環境がない（僕の場合PyOcrを使いたかった）
- N:Nをfirestoreで実現するのが難しい
- DBの更新でPromiseの嵐になる
ただLTの後に詳しい方々の意見を伺うことができ、いくつかのデメリットは回避方法がありそうでした。 （LT後に周りの方々の意見を伺うことができるのが勉強会におけるいちばんのメリットですね）
教えていただいたデメリット回避方法
firestoreは参照時でなく格納時に冗長してデータを持たせる
まず１つ目がデメリットの2,3個目に関連する話ですが、 firestore(NoSQL)はデータ格納の思想がRDBと大きく違っているというものでした。 RDBに慣れている身からすれば「正規化で冗長な情報を削る」ことをしがちですが、 firestoreだとむしろ助長な情報を持たせるのが正しいようです。 これは「いつ欲しいデータを組み立てるか」の違いなのですが、 まとめると以下の表のような形になります。
| 段階 | RDB | firestore |
|---|---|---|
| データ取得時 | 正規化を行いデータの助長化を防ぐ | 参照時のことを考えデータを組み立てておく(冗長を許容) |
| データ参照時 | SQLでテーブルを結合し欲しいデータを組み立てる | 組み上がったデータを参照するのみ |
思想の違いがどこからくるのかはわからないですが、 firestoreは参照時の処理をなるべく少なくして応答速度をあげることを考えてるんじゃないかと推測しています。 なおfirestoreのデータ格納時の組み立て（データ伝搬）にfirebase functionが活躍するようです。
FirestoreのDatastoreモード
「firebaseってなんでSQL投げられないんだろう…」ってぼやいていたら教えてもらいました。 Datastoreモードは使ったことがある方がいらっしゃらず珍しい機能のようですが、 時間がある際に使い勝手等調べてみようと思います。
GASを使えば簡易OCRを行うことができる
最後がデメリット１つ目に関連する話で、 GASを使えば簡単なバッチができる＋OCRの場合は簡易的にやる方法があるというものです。 やり方がかなりトリッキーなので実際に使うかどうかは悩みどころですが、 全く新しい発想だったのでとても興味深かったです。
感想
今回firebaseに関して登壇した内容をまとめさせていただきました。 firebaseは初めて数ヶ月の状態だったので少し迷ったのですが、 自分の悩みなどを発信することで有識者の方からいろいろ教えていただくことができとても良い機会でした。 今後も発信量を増やし引き続き技術面の向上に努めていこうと思います。