【问题标题】:Separating Firebase Functions Into Self-Contained "Packages" (Not separate files - entirely separate packages)将 Firebase 功能分离为独立的“包”(不是单独的文件 - 完全独立的包)
【发布时间】:2021-01-02 03:15:53
【问题描述】:

原始问题 - 见最后答案

我们已经使用 Firebase 函数 2 年多了,已经积累了超过 120 个 HTTP、可调用、触发和计划函数,所有这些函数都从单个 functions/index 调用并由单个 package.json 管理,可能像你们很多人。您可以想象,我们有一些 依赖项,我们不愿更新,因为它需要经过、测试等大量代码。所以这让我开始思考,我我问你们中是否有人这样做过或者知道为什么这行不通...

查看 GCP 仪表板,每个功能都是一个独立的独立服务。但是如果你从那里下载代码,你最终会得到所有 120 多个函数、节点模块等的完整构建。所以如果我在我的单个 functions 目录上运行 npm deploy(如果配额不是问题) ,看起来像

  1. Firebase 工具在我的机器或 CI 工具上抓取我的单个构建
  2. 复制 120 多次,然后
  3. 将整个构建的完整副本推送到每个函数中

这让我开始思考 - 考虑到我不能并且不想构建我的整个项目并一次部署所有功能,我是否必须拥有它们全部在一个 functions 目录中,共享一个 package.json 和依赖项,并从单个 functions/index 导出?

有什么我不能有的理由吗,例如:

- functions

  - functionSingleA (running on node 10)
    - lib/index.js
    - package.json (stripe 8.92 and joi)
    - src/index.ts
    - node_modules

  - functionGroupB (running on node 12)
    - lib/index.js
    - package.json (stripe 8.129 and @hapi/joi)
    - src/index.ts
    - node_modules

我知道我失去了一次性部署的能力,但由于配额,我不再拥有这种奢侈。除此之外,还有什么理由这不起作用?毕竟,据我所知,Firebase 函数只是具有内置 Firebase 凭据的单个无服务器云函数。是我遗漏了什么,还是你这样做并且它工作正常(或破坏了一切)?

Google Firebase 团队的回答

Firebase 工程师通过支持确认这是绝对可行的,但也请查看我和 @samthecodingman 之间的讨论。您可以将您的功能分解为具有不同 package.json 文件和依赖项的完全独立的模块或组,并部署每个(单独或作为组)而不影响其他功能。

您失去的回报是使用firebase functions deploy 命令部署所有功能的能力(尽管@samthecodingman 提供了一个解决方案),并且您失去了在本地模拟功能的能力。我还没有解决方法。

【问题讨论】:

    标签: firebase google-cloud-functions


    【解决方案1】:

    应该可以通过调整文件结构来实现:

    - functionProjects
      - deployAll.sh
      - node10
        - deploy.sh
        - firebase.json
        - functions
          - lib/index.js
          - package.json (stripe 8.92 and joi)
          - src/index.ts
          - node_modules
      - node12
        - deploy.sh
        - firebase.json
        - functions
          - lib/index.js
          - package.json (stripe 8.129 and @hapi/joi)
          - src/index.ts
          - node_modules
    

    作为一个粗略的想法,您应该可以使用脚本来perform targeted deployments。使用目标部署命令,它应该保持其他功能不变(即它不会要求您删除缺失的功能)。

    每个deploy.sh都要把工作目录改到它所在的位置,然后执行有针对性的部署命令。

    #!/bin/bash 
    # update current working directory to where the script resides
    SCRIPTPATH=$(readlink -f "$0")
    SCRIPTPARENT=$(dirname "$SCRIPTPATH")
    pushd $SCRIPTPARENT
    firebase deploy --only functions:function1InThisFolder,functions:function2InThisFolder,functions:function3InThisFolder,...
    popd
    

    deployAll.sh 文件只执行每个“子”文件夹的deploy.sh

    #!/bin/bash
    /bin/bash ./node10/deploy.sh
    /bin/bash ./node12/deploy.sh
    

    这需要维护deploy.sh 中的函数列表,但我不认为这是一个太高的要求。您可以模拟 firebase-functions 库,这样对 functions.https.onRequest() 的调用(以及其他函数导出)只需返回 true 并根据需要使用它来获取函数的动态列表。

    您还可以通过将"functions": { { "source": "." } } 添加到各自的firebase.json 文件中来展平文件结构,以便./node10./node12 是部署的函数目录(而不是嵌套的functions 文件夹)。

    【讨论】:

    • 所以我真正放弃的只是一次模拟整个套件。但除此之外,您似乎同意它们确实是自包含的无服务器功能。从依赖的角度将它们分开应该没有问题?
    • 我什至没有想到你不能一次全部模仿它们。并不是说无论如何您都可以同时模拟 node10 和 node12 函数。我经常在一个项目中同时运行“不同的构建”,您只需要能够确定当前部署的是哪个构建,特别是如果您有共享代码的功能。
    • 关于您所说的复制 120 多次的部分,这是 CLI 执行验证检查以确保在部署之前可以正确启动每个功能。最后一部分是上传整个函数目录并将函数链接到该公共代码部署的位置。如果您使用有针对性的部署,选定的功能将切换到该新版本,但未触及的功能仍将连接到旧版本。
    • 重新“复制了 120 次” - 我明白你的意思,但我的意思是整个包被上传到每个函数,所以看起来每个函数都可以单独构建依赖项,只要它是单独部署的。我认为我们同意这是可能的,只要我了解我可能要放弃的内容(即,模拟整个套件,一次性部署)。我还获得了 Firebase 支持的票。如果我在接下来的 24 天内得到官方答复,我会发布它。如果没有,我会接受。谢谢!
    猜你喜欢
    • 2011-08-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-11-12
    • 1970-01-01
    相关资源
    最近更新 更多