在 google-api-nodejs-client 中使用 Firebase App Hosting API:安装、认证与构建部署编程指南

发布时间:2026/10/15 3:43:19
在 google-api-nodejs-client 中使用 Firebase App Hosting API:安装、认证与构建部署编程指南 后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载Firebase App Hosting 是 Firebase 面向动态 Next.js 与 Angular 应用的一站式部署平台而google-api-nodejs-client仓库中的googleapis/firebaseapphosting子包将其 REST 能力封装为类型安全的 Node.js 接口允许开发者绕过默认 Console 与 CLI 流程通过代码干预构建过程、从外部 CI/CD 触发构建、甚至直接从预构建容器镜像部署。本文以仓库内生成的客户端源码src/apis/firebaseapphosting为依据带你掌握该子包的安装、认证、资源结构以及构建/回滚等核心操作的编程方法。Firebase App Hosting 客户端能做什么根据 子包 README 与 v1 源码 中的 API 描述Firebase App Hosting 旨在简化动态 Next.js 和 Angular 应用的开发与部署提供内置框架支持开箱即用的 Next.js / Angular 构建能力GitHub 集成通过 Developer Connect 连接外部源码仓库监听分支变更自动构建与其他 Firebase 产品Cloud Run、Artifact Registry、Cloud Build 等的深度集成。而使用本客户端 API 的核心价值在于在默认 Console 与 CLI 工作流之外以编程方式介入 Firebase App Hosting 的构建流程并添加自定义功能典型场景包括从外部 CI/CD 工作流如 Jenkins、GitLab CI、自有流水线触发构建从预构建的容器镜像直接部署跳过源码构建阶段。安装子包在任意 Node.js 项目Node 版本要求见下中按 README 给出的命令安装独立子包$ npm install googleapis/firebaseapphosting该子包以独立 npm 包形式发布其元数据在 src/apis/firebaseapphosting/package.json 中可见包名为googleapis/firebaseapphosting主入口为build/index.js类型声明为build/index.d.ts运行时依赖googleapis-common提供认证、请求封装等基础设施并声明node: 22.0.0作为引擎要求。如果你不希望拆分子包安装也可以直接安装完整的googleapis主包然后通过google.firebaseapphosting(v1)获取同一 API 客户端实例见下文“初始化客户端”。初始化客户端与版本选择从 src/apis/firebaseapphosting/index.ts 的源码结构看该子包同时导出了两个 API 版本并通过重载函数firebaseapphosting(versionOrOptions)统一入口export const VERSIONS { v1: firebaseapphosting_v1.Firebaseapphosting, v1beta: firebaseapphosting_v1beta.Firebaseapphosting, };使用方式有两种等价写法源码 JSDoc 示例见 v1.ts// 方式一安装独立子包 const {firebaseapphosting} require(googleapis/firebaseapphosting); const client firebaseapphosting(v1); // 方式二使用 googleapis 主包本仓库推荐的全量入口 const {google} require(googleapis); const firebaseapphosting google.firebaseapphosting(v1);其中v1对应稳定版 API对应源码文件 v1.tsv1beta对应测试版 API对应源码文件 v1beta.ts适合体验尚未稳定的新能力。认证与授权OAuth 2.0、API Key 与服务账号子包继承googleapis-common的认证体系。在 v1.ts 的StandardParameters中每个请求都可通过auth参数指定如下任一凭据类型auth?: string | OAuth2Client | JWT | Compute | UserRefreshClient | BaseExternalAccountClient | GoogleAuth;对应的三种主流认证方式OAuth 2.0用户授权面向需要用户上下文的应用如触发用户项目的构建在源码示例中统一使用GoogleAuth配合cloud-platform作用域const auth new google.auth.GoogleAuth({ scopes: [https://www.googleapis.com/auth/cloud-platform], }); const authClient await auth.getClient(); google.options({auth: authClient});API Key轻量场景直接传入key参数即可StandardParameters.key字段见 v1.ts标识项目并提供配额与用量统计JWT 服务账号令牌服务端自动化场景如 CI/CD 流水线使用服务账号私钥签发的 JWT通过JWT客户端注入。由于 App Hosting 涉及构建、部署等管控类操作所有生成的方法示例均以https://www.googleapis.com/auth/cloud-platform作为所需作用域见 v1.ts 等处的 JSDoc。资源层级Backend、Build、Rollout 与 Traffic从 v1.ts 的类定义可以梳理出客户端的资源树Firebaseapphosting └─ projects └─ locations ├─ backends │ ├─ builds │ ├─ domains │ ├─ rollouts │ └─ traffic └─ operationsBackend后端App Hosting 的首要资源源码注释A backend is the primary resource of App Hosting见 v1.ts代表一个部署目标。其字段包括appId关联的 Firebase Web App ID、codebase外部源码仓库连接、serviceAccount、environment、servingLocality、uri等Build构建针对某个 backend 的源码构建产物。其source字段支持三类来源Schema$BuildSourcearchive归档包、codebaseGit 代码库、container容器镜像Rollout发布把某个 Build 应用为线上版本可配合RolloutPolicy实现基于分支的自动发布Traffic流量控制版本间的流量分配支持按百分比切分的TrafficSplit用于灰度发布见 Schema$TrafficSplitDomains自定义域名管理与 DNS/证书相关的自定义域名状态certState、hostState、ownershipState见 Schema$CustomDomainStatus。从外部 CI/CD 触发构建完整代码示例这是 README 强调的核心自定义能力——绕过 Firebase Console 与 CLI由你自己的流水线驱动构建。以下代码取自 v1.ts 中builds.create方法的内嵌 JSDoc 示例并补充了参数说明const {google} require(googleapis); const firebaseapphosting google.firebaseapphosting(v1); async function main() { // 认证使用应用默认凭据 cloud-platform 作用域 const auth new google.auth.GoogleAuth({ scopes: [https://www.googleapis.com/auth/cloud-platform], }); const authClient await auth.getClient(); google.options({auth: authClient}); // 触发一次 App Hosting 构建 const res await firebaseapphosting.projects.locations.backends.builds.create({ // 必填构建所属 backend 的完整资源名 parent: projects/my-project/locations/my-location/backends/my-backend, // 必填本次构建的 ID buildId: my-build-id, // 可选幂等请求 IDUUID用于超时重试去重 requestId: placeholder-value, // 可选仅校验并填充默认值不真正创建资源 validateOnly: placeholder-value, requestBody: { // 构建配置源码来源等 source: { // 三选一Git 代码库 / 归档包 / 容器镜像 codebase: { branch: main, // 基于某分支最新提交 // commit: abc123, // 或指定提交 }, }, // 可选应用配置环境变量、Cloud Run 运行参数等 config: {}, }, }); console.log(res.data); } main().catch(e { console.error(e); throw e; });关键参数说明对应 v1.ts 中的生成注释参数必填说明parent是格式为projects/{project}/locations/{locationId}/backends/{backendId}buildId是本次构建的期望 IDrequestId否唯一请求 ID用于幂等重试服务端在首次请求后至少 60 分钟内去重注意零 UUID00000000-0000-0000-0000-000000000000不被支持validateOnly否为 true 时只做校验并填充默认值不持久化、不创建任何资源requestBody.source是构建来源可为 codebase / archive / container 三者之一其中builds.create方法在 v1.ts 的实现中会构造POST https://firebaseapphosting.googleapis.com/v1/{parent}/builds请求parent为必填路径参数并返回标准的 LRO长时运行操作Schema$Operation——也就是说构建是异步执行的返回的 Operation 可用于轮询最终状态。使用归档包或容器镜像作为构建来源除了从 Git 代码库构建客户端还支持两种“跳过源码仓库”的来源Schema$BuildSource1. ArchiveSource归档包见 Schema$ArchiveSourcesource: { archive: { // Cloud Storage 中的 .zip 或 .tar.gz 归档包含待部署源码 userStorageUri: gs://my-bucket/app-src.tar.gz, // 或存储桶中归档的签名 URL // externalSignedUri: https://storage.googleapis.com/...?X-Goog-Signature..., // 可选归档内相对根目录的部署子目录monorepo 场景 rootDirectory: apps/web, }, }2. ContainerSource容器镜像见 Schema$ContainerSource直接指定 Artifact Registry 中的镜像 URI完全跳过源码构建source: { container: { image: us-docker.pkg.dev/my-project/my-repo/app:latest, }, }值得一提的细节ArchiveSource.author字段在源码注释中标记为Deprecated: Not used说明该字段已废弃实际构建作者信息不再通过它传递。代码库连接与 monorepo 根目录若希望 App Hosting 监听仓库事件自动构建需要在 Backend 上配置codebaseSchema$CodebaserequestBody: { codebase: { // 必填Developer Connect 的 gitRepositoryLink 资源名 repository: projects/my-project/locations/us-central1/connections/my-conn/gitRepositoryLinks/my-repo, // 可选monorepo 中部署根目录应包含 package.json 或 apphosting.yaml rootDirectory: apps/web, }, }从源码注释可以确认rootDirectory默认为仓库根如果部署 monorepo应设置为包含package.json或apphosting.yaml的目录。连接必须通过 Firebase Console 中的 Firebase App Hosting GitHub App 建立。发布与流量灰度Rollout 与 Traffic创建 Build 后通过rollouts.create将其发布为线上版本示例见 v1.tsconst res await firebaseapphosting.projects.locations.backends.rollouts.create({ parent: projects/my-project/locations/my-location/backends/my-backend, rolloutId: my-rollout-id, requestBody: { build: projects/my-project/locations/my-location/backends/my-backend/builds/my-build-id, }, });如果需要灰度而非全量切换可配置 Rollout 策略与流量切分。RolloutPolicySchema$RolloutPolicy支持codebaseBranch指定触发自动构建/发布的分支disabled/disabledTime禁用自动发布ignoredPaths/requiredPaths按文件路径模式GLOB最多 100 条决定哪些变更触发发布ignoredPaths优先级更高两者均未设置时默认所有路径变更都触发。流量侧由traffic资源管理其TrafficSet通过splits列表Schema$TrafficSplit按百分比把请求分配到不同版本适合金丝雀发布。自定义域名与 DNS 状态domains子资源用于把自定义域名接入 backend。从 Schema$CustomDomainStatus 可以看到域名接入涉及三个维度的状态机certStateSSL 证书状态必须为CERT_ACTIVE才能完成创建hostStateDNS 是否已把流量指向 App Hosting必须为HOST_ACTIVEownershipState域名归属校验必须为OWNERSHIP_ACTIVE。相关的DnsUpdatesv1.ts会给出discovered当前实测记录与desired期望记录两组 DNS 记录集帮助开发者自查并修正 A / CNAME / TXT / CAA 记录最终完成上线。源码导读从入口到请求发送如果想深入理解该客户端的实现可按以下路径阅读仓库源码入口与版本分发src/apis/firebaseapphosting/index.ts —— 定义VERSIONS映射、firebaseapphosting()工厂函数与auth导出主客户端类v1.ts ——Firebaseapphosting类持有context并挂载projects资源资源与方法v1.ts ——Resource$Projects到Resource$Projects$Locations$Operations共 8 层资源类每个方法内部通过createAPIRequest构造 REST 请求如builds.create使用POST /v1/{parent}/builds见 v1.ts数据模型v1.ts —— 全部Schema$*接口即 REST JSON 结构的 TypeScript 类型定义测试版v1beta.ts —— 与 v1 平行的 beta 版本实现。许可与参与贡献该子包与整个仓库一样采用 Apache 2.0 许可完整许可文本见仓库根目录 LICENSE版本变更记录见 CHANGELOG.md。需要说明的是仓库中所有src/apis/*目录均为自动生成代码文件头标注THIS FILE IS AUTO-GENERATED因此不建议手工改动生成文件如遇缺陷或新版本需求应在主仓库 googleapis.ts 对应的生成链路层面跟进。赞分享后端【免费下载链接】google-api-nodejs-clientGoogles officially supported Node.js client library for accessing Google APIs. Support for authorization and authentication with OAuth 2.0, API Keys and JWT (Service Tokens) is included.项目地址https://gitcode.com/gh_mirrors/go/google-api-nodejs-client点击查看免费下载相关推荐基于 google-api-nodejs-client 使用 Google Data CatalogNode.js 客户端库安装、认证与核心 API 实战指南基于 google api nodejs client 使用 Google Data CatalogNode.js 客户端库安装、认证与核心 API 实战指南后端google-api-nodejs-client 官方 Node.js 客户端库实战指南安装、OAuth2 认证与 Google API 调用google api nodejs client 官方 Node.js 客户端库实战指南安装、OAuth2 认证与 Google API 调用 本篇指南以 R后端google-api-nodejs-client 中 Cloud DomainsdomainsAPI 的安装、配置与使用指南google api nodejs client 中 Cloud DomainsdomainsAPI 的安装、配置与使用指南 导读 本文面向在 Node.j后端上一篇Kubernetes SIG Security 2021 年度全景社区驱动的安全治理、KEP 落地与子项目演进下一篇Velero 插件管理命令完全指南velero plugin add/remove 的使用与底层原理创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询