我在做什么？

1. 我目前正在开展一个项目，该项目将来会连接到云。
2. 我有一个将连接到云的 PLC。当“进程”开始时，PLC 会不断地向某个数据库发送数据。
3. 然后应该可以通过网站查看数据库中的数据。
4. 理想情况下，该过程结束后，应将数据放入 PDF 或其他一些可打印文件中。

我调查了谷歌的 firebase 生态系统，如果我理解正确的话，这是“完美”的架构：

1. 左边是我的 PLCMQTT与Cloud IoT core服务通信。
2. 从那里的消息将进入Cloud Firestore通过Cloud Functions（通过邮件我指的是PLC的配置选项和传感器数据）。
3. 用户将通过托管在 上的网站与设备进行通信Firebase Hosting。
4. 最后，我可以将 PDF 文件保存到Firebase Storage服务中。

起初，我觉得这一切都非常令人兴奋！我会在一个屋檐下，在一个地方提供我所有的服务。计费也不是那么糟糕。 但是要正确设置所有内容需要做很多工作。

我的另一个架构想法：

所以我开始想，也许我可以Firestore 通过REST API调用直接与 PLC通信……但是 Firestore REST API 现在还不支持侦听器（仅.GET和 .POST方法）。而且，如果我.GET每秒都向来自Firestore database（用户更改某些 PLC 配置的）新数据发出请求，它会变得非常昂贵。所以这不是办法。

1. 然后我发现了关于Googles SpreadSheets. 它似乎可以解决我所有的问题。
2. 它可以存储无限量的数据。
3. 定价不取决于REST API我拨打了多少电话。因此，即使Google Spreadsheets REST API不支持侦听器，我也可以通过.GET定期调用该方法来解决它。
4. 我可以SpreadSheets通过我的网站与甚至交流。

有了这个解决方案，我将只用 1 个就摆脱 4 个 Google 服务：

1. 我不需要Google IoT core- PLC 可以通过 REST API 直接与电子表格进行通信。
2. 我不需要Firestore——Google Spreadsheets可以存储数据就好了。
3. 我不需要Firebase Functions——不需要将任何数据推送到数据库。
4. 我不需要Firebase Storage——我可以将文件另存为Googles Spreadsheets然后打印出来。

问题：

所以现在我有点困惑。因为第一个架构（没有电子表格）看起来很完美。但我不明白为什么我可以免费用谷歌电子表格替换所有这些！

1. 我是否忽略了什么？
2. 使用Google SpreadSheetsfor IoT 解决方案是否存在隐藏的问题？
3. 这样使用正常Google SpreadSheets吗？
4. 您建议使用什么架构？第一个与整个Google Firebase生态系统或第二个只有SpreadSheets？

如果您认为这是错误的 stackexchange 站点，请善待并将我重定向到正确的站点，非常感谢！