为什么小型 Firebase Functions 应用程序不使用单个 Function 来处理逻辑？
Why wouldn't a small Firebase Functions app just use a single Function to handle logic?
...除了单独的性能监控和日志记录的好处。
对于日志记录，我相信我可以通过将“例程”的名称手动添加到每个调用来获得粒度。这就是现在系统不同部分的几个离散函数的情况：
有多个自动日志：例如例程的开始和结束。找出某些例程的成本会更具挑战性，但这并非不可能。
我希望应用程序的整个逻辑由单个 handle 函数处理的原因是减少冷启动：一个函数意味着只有一个容器可以在用户很少时持久保持活动状态应用程序。
如果一个月大约是 260 万秒，并且我们假设系统始终使用 1 GB RAM 和 1 GHz CPU 频率，那就是：
2600000 * 0.0000025 + 2600000 * 0.000001042 = USD.21 a month
...至少一个实例。
我还应该声明，我的所有函数都具有最低限度的全局范围代码；它只是设置 Firebase 资产（RTDB 和 Firestore）。
从计费、性能（基于用户等待时间）和 user/developer 体验的角度来看，有什么理由让我的所有功能保持独立是明智的？
我也接受这样的回答：“所有逻辑的单一功能是合理的”，只要有理由。
谢谢！
如果您的应用非常小，有大约 5 个端点且流量非常低。当然你可以做这样的事情。但为什么不这样做：
- 计费和性能
要认识到的重要一点是，每个请求都会创建一个新的函数实例。这意味着可能同时有 10 个 运行时间.
如果您只想让 1 个实例处理所有流量，您应该探索 GCP Cloud run，其中您有 1 个容器处理多个请求并仅在它不够用时扩展。
假设您有多个端点，每个端点都有不同的性能要求。
- 1只需要128MB或RAM
- 1 可能需要 1GB RAM
（仅供参考：您也可以通过 RAM 设置控制 CPU MHz of the function - 在某些情况下可以加快执行速度）
如果你只有 1 个函数和 1GB 的内存。每个请求都会分配这样的函数，在某些情况下，大部分内存都会被浪费。
但是，如果您将其拆分为多个，一些请求将需要更少的资源，并且当我们谈论更大的执行量/月时，可以为您节省 $。 （数万+）。
让我们想象一下函数，3秒执行，10k executions/month:
- 128MB 需要 0.0693 美元
- 1024MB 需要 0.495 美元
如您所见，对于小型应用程序，差别可能不大。但如果你扩展它很重要。（*成本可能因数据中心而异）
至于日志，我觉得不重要。通常在较大的系统中，消息可能会通过多个函数传输，因此您无论如何都必须处理它。
至于冷启动。你只需要好的 UI 来促进这一点。起初我在我们的应用程序中担心它，但后来，你就会习惯一些动作可能需要大约 2 秒才能执行（冷启动）。无论如何你都应该有UI“加载”，因为你不知道由于连接不良，该功能是否会花费~100ms或3s。
...除了单独的性能监控和日志记录的好处。
对于日志记录，我相信我可以通过将“例程”的名称手动添加到每个调用来获得粒度。这就是现在系统不同部分的几个离散函数的情况：
有多个自动日志：例如例程的开始和结束。找出某些例程的成本会更具挑战性，但这并非不可能。
我希望应用程序的整个逻辑由单个 handle 函数处理的原因是减少冷启动：一个函数意味着只有一个容器可以在用户很少时持久保持活动状态应用程序。
如果一个月大约是 260 万秒，并且我们假设系统始终使用 1 GB RAM 和 1 GHz CPU 频率，那就是：
2600000 * 0.0000025 + 2600000 * 0.000001042 = USD.21 a month
...至少一个实例。
我还应该声明，我的所有函数都具有最低限度的全局范围代码；它只是设置 Firebase 资产（RTDB 和 Firestore）。
从计费、性能（基于用户等待时间）和 user/developer 体验的角度来看，有什么理由让我的所有功能保持独立是明智的？
我也接受这样的回答：“所有逻辑的单一功能是合理的”，只要有理由。
谢谢！
如果您的应用非常小，有大约 5 个端点且流量非常低。当然你可以做这样的事情。但为什么不这样做：
- 计费和性能
要认识到的重要一点是，每个请求都会创建一个新的函数实例。这意味着可能同时有 10 个 运行时间.
如果您只想让 1 个实例处理所有流量，您应该探索 GCP Cloud run，其中您有 1 个容器处理多个请求并仅在它不够用时扩展。
假设您有多个端点，每个端点都有不同的性能要求。
- 1只需要128MB或RAM
- 1 可能需要 1GB RAM
（仅供参考：您也可以通过 RAM 设置控制 CPU MHz of the function - 在某些情况下可以加快执行速度）
如果你只有 1 个函数和 1GB 的内存。每个请求都会分配这样的函数，在某些情况下，大部分内存都会被浪费。
但是，如果您将其拆分为多个，一些请求将需要更少的资源，并且当我们谈论更大的执行量/月时，可以为您节省 $。 （数万+）。
让我们想象一下函数，3秒执行，10k executions/month:
- 128MB 需要 0.0693 美元
- 1024MB 需要 0.495 美元
如您所见，对于小型应用程序，差别可能不大。但如果你扩展它很重要。（*成本可能因数据中心而异）
至于日志，我觉得不重要。通常在较大的系统中，消息可能会通过多个函数传输，因此您无论如何都必须处理它。
至于冷启动。你只需要好的 UI 来促进这一点。起初我在我们的应用程序中担心它，但后来，你就会习惯一些动作可能需要大约 2 秒才能执行（冷启动）。无论如何你都应该有UI“加载”，因为你不知道由于连接不良，该功能是否会花费~100ms或3s。