公司范围内 Google Apps 脚本的架构答案

【问题标题】：Architecture of a company-wide Google Apps Scripts公司范围内 Google Apps 脚本的架构
【发布时间】：2017-06-29 20:10:18
【问题描述】：

在我们公司，我们大量使用 Google 电子表格。我想自动化一些事情，例如每分钟我想调用我们银行的 API 并将所有新交易保存到电子表格中。

我在官方文档中缺少的是一些主要的架构最佳实践。

问题的第一部分：谁应该是这种用户中立的公司范围脚本的所有者/运行者？我不想将其绑定到我的个人帐户。即使有一天我离开公司，我也希望它能够无缝运行。是否需要一些人工技术用户？

如果这有什么不同，我们计划在未来转向团队驱动。

问题的第二部分：我希望脚本具有持久存储（在上面的示例中 - 用于记录事务）。我正在考虑成为一个规则，即每个脚本都绑定到充当其数据存储的电子表格。这是个好主意吗？

【问题讨论】：

一般来说，对于多人使用的 Apps Script 项目，和/或如果脚本发生问题会非常糟糕，您应该使用“独立”的 Apps 脚本文件。您只需右键单击云端硬盘中的文件并选择“下载”即可备份 Apps 脚本文件。使代码可供多个用户使用的最佳选择是使用附加组件。附加组件不需要向公众发布。它可以在域范围内发布。您应该能够设置一个在域内通用的用户帐户。
但是您的组织应该有关于如何访问每个人的帐户的书面文档。这不是真正的 Apps 脚本问题或文件问题。这基本上是人力资源的责任。至于持久存储，它取决于一类数据是否超过 9k 字节。就是这样，然后我将数据存储在脚本之外。 9k 是属性服务中任何一个“属性”的限制。
库不安全，如果您想阻止任何用户获取代码。可能很少有人知道如何从库中获取代码，但是对于任何有时间和动力的人来说，他们可能会发现。

标签： google-apps-script google-sheets google-docs

【解决方案1】：

我通常建议客户为我提供一个“人工技术用户”，如您所说，以使该所有者保持活力并远离我的个人帐户。这也避免了用完我的每日配额，特别是对于常规触发器。

我会避免将脚本绑定到 GSheet，因为您可能会在将来使用 GitHub 或创建附加组件时遇到问题。我通常在一个单独的库 (Bruce McPherson did various tests and never found a performance hit) 中制作所有脚本，然后如果需要，将它们与一个非常小的脚本链接到 GSheet 中包含的脚本。这样可以在实时使用脚本时简化单独的开发。

GSheets 确实提供了相当数量的存储空间（200 万个单元格），但如果您达到了这一点 - 而且工作表确实会变慢 - 请看看使用 Firebase，您可以获得 1GB 的免费空间，并且有 a great Firebase library。

对于 Apps 脚本开发有各种一般性建议。我链接了几个here。

脚本编写愉快！

【讨论】：

我发现了一个 Google 术语“服务帐户”。它可以作为我们所说的人造账户吗？您使用它还是使用成熟的 Google 用户帐户？
一个成熟的帐户。