从昨天所提及的架构，让你在爬虫获取资料的情境下使Cloud Function能各司所职。
并使维护专案的难度下降。
今天的文章会简单带各位了解RealTime Database可以如何被运用到你的专案上。
而 Cloud Function 传递资料的流程会发生什麽变化

架构图

基於昨天的基础架构，现在我们的Cloud Functions依旧执行类似的任务，
但在两者资料传递间多了一个资料库来协助暂存资料。
因此两个Cloud Functions现在推送或拉取资料的对象变成我们的资料库。

使用Firebase RealTime Database

它是一种NoSQL型态的资料库，使用键与值来储存与索引资料。
透过它我们可以轻易地建立可以即时同步数据的小型资料库!

在我们的专案中，他可以协助我们解决以下情境的问题：

• 爬虫抓取的资料需要不断被存取，但过於频繁读取原始网页爬虫机器人可能会被封锁权限无法读取资料。
• 你使用的Open API是更新频繁的资料，而且你建立的Action之主要功能需要频繁读取资料。
  但Open API设有每日读取资料之上限。因此需要有第二方案来存取资料。

参考资料与延伸阅读

• Firebase 实时数据库
• Firebase 教学 - RealTime Database 安装与使用

下一步...

现在你已经建立起一组 Cloud Function 以及介於两者间的资料库了
看似很美好，但Cloud Function本身是事件驱动(event driven)的服务。
无法自行协助我们进行资料拉取以及上传的动作，这导致你的Action去资料库会拉不到所需的资料。
因此，在明日的文章中将会简述如何透过GCP服务的帮助解决这个烫手山芋!