使用者利用Firebase Auth註冊後，會需要利用Trigger機制進行後續的處理。Trigger的官方文件裡有寫著二個Trigger

• Create
• Delete

多數的遊戲使用者並不會用delete的方式將其帳號移除，但註冊這動作確是不可少的。雖然今天沒有辦法深入了解，但概念上會是玩家註冊後利用Trigger方式在Firestore裡產生需要的Collection，比方說Inventory、Status，Unit等。

Firestore的用法是建議多個Collection的使用方式，雖然它是存Json，但不建議將所有的資料都放在同一個json裡，像是這樣的寫法就不建議

{
  "inventories": [
    {
      "id": "item001",
      "kind": "weapon"
    }
  ],
  "units": [
    {
      "id": "archer",
      "amount": 10
    }
  ]
}

但分柝成不同的collection就比較適合。

從使用限制上去看，Firestore每一秒最多只能寫入1000筆Document，在Firestore裡，每個Collection裡有多個Document，如果按照上述的方式進行使用，就表示一秒裡最多就是1000個玩家的某一部份資料可以被更改。至於讀取，沒有筆數的限制，但我記得好像有容量上的限制，也就是說就算是讀取資料，也不會是無上限的。

在這樣的用法上延伸出來的就是如果，一秒鐘的更新數量多於1000筆，到底要怎麼處理呢？在網路上的資料是建議要做buffer(queue?)的方式，也就是先行queue住，在一次處理低於1000筆的量，直到完成。但如果量遠遠多於這個數字，是否在Client端會明顯的變慢。且這樣子的想法，會不會違背stateless的設計。

從實際的數字上去看1秒1000筆，也就說1分鐘就60000筆，而一小時就3600000次Document的更新，如果是小型的專案，正常情況下根本不可能會有這樣的更新數量。而中型以上的專案，官方文件也明說或許Firestore並不適合，可以考量其它的DB方案。

針對讀取的想法，現在已會用Redist進行Leaderboard的資料存放，或許在這樣的架構下，可以直接針對query進行Cache，但這部份還沒有試過，不清楚實值上要怎麼進行。之後要花些時間找文章了解要怎麼利用redist進行query的cache動作。

回到Trigger的部份。它是利用cloud function進行，不知道是否可以用一般的server接收Trigger回來進行處理。如果透過pub sub，也還是需要經過另一層服務，也就是說還是會有一些花費。這部份之後也要進行了解。畢竟，cloud function的免費額度也是有一定的，除了auth trigger要用cloud function處理外(如果沒有其它更好的方法)還有很多其它的部份都要利用cloud function，能有效的運用是最好的。

而cloud function的語言，會想要利用golang進行，這部份除了golang不熟悉外，也要嘗試如何利用serverless framework的方式將code包起來後放入到cloud function裡。這部份一樣是不確定的成分，需要花時間了解怎麼進行。

總之，今天又是沒有辦法實際的展開試驗，只能將想法先記錄下來。