從昨天所提及的架構，讓你在爬蟲獲取資料的情境下使Cloud Function能各司所職。
並使維護專案的難度下降。
今天的文章會簡單帶各位了解RealTime Database可以如何被運用到你的專案上。
而 Cloud Function 傳遞資料的流程會發生什麼變化
架構圖
基於昨天的基礎架構，現在我們的Cloud Functions依舊執行類似的任務，
但在兩者資料傳遞間多了一個資料庫來協助暫存資料。
因此兩個Cloud Functions現在推送或拉取資料的對象變成我們的資料庫。
使用Firebase RealTime Database
它是一種NoSQL型態的資料庫，使用鍵與值來儲存與索引資料。
透過它我們可以輕易地建立可以即時同步數據的小型資料庫!
在我們的專案中，他可以協助我們解決以下情境的問題：
- 爬蟲抓取的資料需要不斷被存取，但過於頻繁讀取原始網頁爬蟲機器人可能會被封鎖權限無法讀取資料。
- 你使用的Open API是更新頻繁的資料，而且你建立的Action之主要功能需要頻繁讀取資料。
但Open API設有每日讀取資料之上限。因此需要有第二方案來存取資料。
參考資料與延伸閱讀
下一步…
現在你已經建立起一組 Cloud Function 以及介於兩者間的資料庫了
看似很美好，但Cloud Function本身是事件驅動(event driven)的服務。
無法自行協助我們進行資料拉取以及上傳的動作，這導致你的Action去資料庫會拉不到所需的資料。
因此，在明日的文章中將會簡述如何透過GCP服務的幫助解決這個燙手山芋!
