快速認識 firebase
前言
自從 heroku 關閉免費 db 後
不論是 AWS 或 GCP(firebase)，現有的免費 db 服務只剩下 NoSQL 了
若初期用量不大，或只是想要弄個作品，直接選用 firebase 是滿好的選擇
所有資料查詢可以無腦寫在前端，省下了後端的開發與維運
若前端打包成純靜態頁面，那維運成本幾乎低到只剩下 firebase 的使用量了！
如果自己有使用GitHub copilot，那會更加舒服！
因為關於 firebase api 的使用，copilot 幾乎可以完美產生…
最初在考量要不要使用 firebase，花了許多時間蒐集資訊
於是整理出來，讓有打算使用的人可以快速進入狀況，省下許多爬文時間！
Authentication
- 使用 social auth 登入後，雖官方說 token 只有一小時，persistance 在 browser 預設是
LOCAL(即永久)，會自動刷新 token。也就是 user 沒按下登出，則是永遠保持登入狀態。其資訊在 indexedDB 記錄 - social auth 是免費的，單純使用他串接多個三方登入會很方便
- 若預計使用 nextjs 開發，現成三方登入的ui按鈕，可以參考修正後的 firebase UI。因現成的firebase-ui library 僅支援 React.Js 17以下的版本。語系的部份依官方教學自行 build 出來使用
價格
- 主要計價方式是以 read write 次數，沒設計好寫法，當超過 free quota 後，易爆量造成預期外的花費
- 當查詢回傳 30 筆資料時，算 read 30 次！故分頁很重要
- 機房選擇台灣，價格是美國的一半！除非 TA 是美國，不然放台灣更佳
- firebase 本身即是後端，可以省下許多開發工時。相當適合開發 MVP 快速試水溫
- 亦相當適合小規模的 Side Project！用量不大、資料簡單的話，可省下後端開發工時，其 free quota 算很夠用
- cloud function 即自己寫的後端 api，須將計價設定成 blaze 後才可以使用。但也有提供免費流量，小規模使用仍不會計價
firestore vs real-time firebase
- real-time firebase 比 firestore 便宜
- firestore 是基於 real-time firebase，再強化功能，仍持續釋出新功能。可以看出來 firebase 主力會是以 firestore 為主
- firestore 用起來更像常規的資料庫；real-time firebase 可以當作單純的 json array 儲存容器
- 若要儲存的結構很明確且單純，那可以用 real-time firebase 省成本。反之使用 firestore 會是更好的選擇
資料結構
- 他是 NoSQL，資料結構就像熟悉的目錄管理，區分 collection(就像目錄)與 document(就像文件)。collection 裡可以再放 collection & document。最深 20 層
- 因為是 NoSQL，若比照 relational DB(關聯式資料庫)習慣規畫結構，讀寫次數很容易比預期多許多造成額外開銷。故不建議以 relational DB(關聯式資料庫) 設計結構
- 官方推薦資料 denormalize(去正規化)，也就是不要害怕重複資料。在 NoSQL 是常見作法。雖異動資料時，write 次數會拉高。大部份情境應是 read >> write
- 當 read 整個 collection 時，子 collection 不會載入。官方推薦用來做
private_metadata存放權限設計或不想公開的資訊 - 一個 document 最大只能 1mb
- 當刪除 【根 collecton(root-collection)】，【子 collection(sub-collection)】不會一起刪除
- 不提供
like %查詢文字%模糊查詢，官方推薦用三方服務達到這功能。推測是因其計價特性，模糊查詢勢必會碰觸所有 document 做判斷，不易計價
安全性
- firebase 本身就像個後端。故關於 db 的查詢、寫入都可以寫在前端。而 table 安全性透過後台的 security 設定
- 在網頁上，安全性的改動都會有記錄，故隨時可以退回
心得
可以感受到，大部份的小型 Side Project
不論是價錢或開發速度上，用 firebase 真的挺舒服！
通常最大的點，應該是處在【不提供like %查詢文字%模糊查詢】了
畢竟搜尋功能很容易出現在 web 服務的
而 web 又不像 APP 可以使用 SQLite 本地保存
比較容易在這裡產生額外的開發功
比如為了做一個簡單的 title filter(但資料量不多)
須特別拉一個欄位保存 title array，每次有異動時，都還得特別維護這個表
只能期望未來 firebase 能提供更好的原生解法，而不是依賴三方服務了！