google-cloud-functions - 创建多个轻量级 Google Cloud Functions 的最佳实践？

Question

Google Cloud Functions 的工作方式似乎是:

您的模块进入 functions目录

那functions然后目录包含 package.json文件以包含所有模块之间的共享依赖关系

每个模块可以包含许多导出函数

google cloud functions 和 firebase functions 意见不一 怎么处理modules中的导出函数

对于 gcp，它似乎是这样工作的:模块被上传，然后你通过 web 界面或命令行指定应该从加载的模块中调用哪个导出的方法

对于 firebase，它似乎是这样工作的:来自 firebase-functions 的监听器方法返回处理程序，但还将触发器元数据附加到该处理程序。 firebase-tools然后，cli 应用程序在本地需要您的代码，获取导出的函数，然后根据来自 firebase-functions 内容的附加元数据为每个导出的方法创建云函数。因此，如果您将所有云功能放在同一个模块中，那么它将为每个云功能多次部署该模块，并且为每个云功能加载整个模块，然后调用特定的导出功能。

如果您将导出的函数配置为 http 触发器，则它使用未定义版本的 express.js，以及捆绑中间件的数量和顺序不定

这很奇怪:

说即使模块 one.js和 two.js在运行时需要不同的包，共享 package.json它们之间意味着它们的启动时间将比单独完成要慢，因为它们都需要安装包的所有依赖项，而不仅仅是他们自己的

如果您在 index.js 中有多个导出函数，如 hi()和 hello() ，然后是 hi云功能也将有hello()尽管没有使用它，但在内存中加载的函数，以及 hello云功能将有hi()尽管没有使用它，但在内存中，至于生成的云函数仍将使用相同的 index.js文件，将该模块中的所有内容加载到内存中，即使不需要其他部分

因此，确保您的云功能以尽可能轻的运行时占用空间以最佳方式运行的最佳实践是什么？谷歌的设计决策似乎意味着您制作的云功能越多，每个云功能捆绑的垃圾就越多，从而减慢它们的速度并增加成本。

另一方面，在我看来，这对 google 来说是一个更好的方法:每个云功能都应该有自己的目录，并且在每个目录中都有一个 package.json文件和 index.js文件。 index.js 文件然后执行 module.exports = function(...args){}或 export default function(...args){} .

通过这种方式，架构与人们期望云功能的运行方式保持一致——因为云功能代表单个功能——而不是云功能是安装所有云功能之间的共享依赖项，然后加载一个模块可以包含多个云功能但只使用一个，然后只执行该加载模块中的一个功能。

有趣的是，Azure Functions 的设计似乎与我期望的云功能运行方式完全一致: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node

Answer 1

我正在使用 modofun ( https://modofun.js.org )，它是基于请求路径的多个操作的路由器。这使我可以将相关函数收集到一个模块中，该模块部署为单个 Google Cloud 函数。该模块中所有函数的依赖关系都是相同的，因此它具有依赖效率。您还可以共享通用的全局资源，例如数据库连接。

我同意单独部署每个功能是一种资源浪费，而且很难维护。

我为我在生产中的 Google Cloud Functions 部署做了这个。