我们弃用 Firebase了 (我们抛弃)

我们已经在 Firebase 上发布了 10 几款应用程序，几乎用到了该平台每个方面的特性，并设计了一个可以实现优雅扩展的手册。可以说，事实已经证明，Firebase 对 K-Optional Software 而言是非常宝贵的工具。

就在 2022 年 3 月，我们的开发人员还在为Firebase Extensions等创新欢呼。遗憾的是，过去几个月的三个主要变化破坏了开发体验，因此，在新项目中，K-Optional 将转向其他替代方案。

Firebase：好的地方

这个归谷歌所有的平台即服务（PaaS）使构建者做出了多项基础设施决策：内容交付网络、NoSQL 数据库事件处理程序和网络拓扑等等。的确，纯从性能上讲，在 AWS/Azure/ GCP 上构建的定制化原生服务包优于 Firebase 套件。但是，当我们考虑到开发时间和维护成本时，Firebase 通常是一个合乎逻辑的选择。

Firebase实时数据库 最初给人的感觉相当具有革命性，特别是在 WebSockets 被广泛接受或 Server-Sent Events出现之前。你可以编写实现实时数据同步的应用程序，而且不需要开发大量的传输逻辑。那些在自制即时通讯应用程序中使用了长轮询请求的的用户肯定会喜欢它。

事实上，Firebase 有许多方面是我们喜欢的：

Firebase：不那么好的地方

另一方面，Firebase 也有不少地方让我们犹豫：

提取机器可读的 CI token

是的，我喜欢将 CI token 直接传递到我的秘密管理器。

citokenRaw=$(firebase login:ci)citoken=$(echo "$citokenRaw" | tail -n 3 | head -n 1)

复制代码

将 Web 配置加入.env 文件

下面这几行代码会下载一个 Firebase Web 片段，并将其转换为适合文件的内容。这个 Web 片段会将站点配置为使用特定的 Firebase 应用程序，并借助环境变量使我们可以跨项目保留脚手架。

# 丑陋 丑陋 丑陋 fbKeysObject=$(firebase apps:list--project=$FB_PROJECT --non-interactive --json| fx '.result[0].appId' | xargs -I {} firebase apps:sdkconfig WEB {}|sed '/{/,/}/!d '| sed -r's/;|firebase.initializeApp|(|)//g')# 构建一个.env文件echo "$fbKeysObject" | jq '.projectId' | xargs -I {} echo "REACT_APP_FB_PROJECT_ID=""{}" > .envecho "$fbKeysObject" | jq '.appId' | xargs -I {} echo "REACT_APP_FB_APP_ID=""{}" >> .envecho "$fbKeysObject" | jq '.storageBucket' | xargs -I {} echo "REACT_APP_FB_STORAGE_BUCKET=""{}" >> .envecho "$fbKeysObject" | jq '.locationId' | xargs -I {} echo "REACT_APP_FB_LOCATION_ID=""{}" >> .envecho "$fbKeysObject" | jq '.apiKey' | xargs -I {} echo "REACT_APP_FB_API_KEY=""{}" >> .envecho "$fbKeysObject" | jq '.authDomain' | xargs -I {} echo "REACT_APP_FB_AUTH_DOMAIN=""{}" >> .envecho "$fbKeysObject" | jq '.messagingSenderId' | xargs -I {} echo "REACT_APP_FB_MESSAGE_SENDER_ID=""{}" >> .env

复制代码

附注结束。综上所述，Firebase 存在的大多数问题都来自谷歌所有权， 它 们让我很恼火。而最近的事态发展引发了我们的反思 ……

不祥之兆

Firebase 近期的三个发展变化让我们确信，未来属于这样的工具。

GCP 偏向之一：通过移除 Firebase 的特性迫使人们迁移到 GCP

在过去的几个月中，Firebase 去掉了仪表板中的 Cloud Function 日志。如果需要，则可以通过他们提供的链接在 Google Cloud Console 仪表板中查看。

我还注意到，无法在 Firebase Storage 仪表板上下载文件了；必须导航到单独的 GCP 平台。

GCP 似乎正在蚕食 Firebase 开发环境。

从运营的角度来看，这是合理的。但是，简化 Firebase 的云体验会使它失去大部分的价值；我们客户并不想了解 GCP。在最近的 Firebase 项目中，我在想我们是否应该推出自定义的服务。我相信，谷歌不会介意开发人员放弃 Firebase 而单纯使用 GCP。

近期 Cloud Function 部署的速率限制

Cloud Function CI/CD 降级。Firebase对Cloud Function部署强制执行每100秒80次调用的配额。据我所知，这个配额已经存在有一段时间了。

但最近，Cloud Function部署在达到这个配额后开始悄然失败。这很棘手，因为 80 个端点并不算多，而且Firebase至今没有提供一种简洁的方法，让我们可以只部署更改后的Cloud Function。

对于这个问题，K-Optional Software 几乎在同一时间收到了多个关于项目（不是我们的项目）的咨询请求，一切都表明，是 API 的突然变化造成了麻烦。

我考虑了以下两种变通方法：

GCP 偏向之二

最后，Firebase 越来越多地引导用户使用 GCP 获取基本服务。在过去的几个月里，开发人员偶尔会反馈由于缺少权限而导致Firebase Hosting失败。我们的团队上周也开始报告这个问题。为什么 Firebase Hosting 会需要 Cloud Function授权，这让我很困惑。无论如何，Google Cloud Console 是添加此权限的唯一方法。

尽管 Firebase 开发有所下降，但我最近还是经常在这个权限仪表板上看到自己。

Cloud Function部署文档

最近，作为考察过程的一部分，我们在 Supabase 上开发了一些小项目。其开发体验令人愉快，特别是行级安全，那与 Firestore 规则类似，但更为强大。Supabase 正基于 Deno 开发他们的无服务器函数套件，这表明他们对优秀的技术很重视。

我们喜欢 Supabase 使用的PostgreSQL。我们计划在可伸缩性方面做更多的研究，因为 SQL 数据库不能像 NoSQL 数据库那样增长。尽管如此，Supabase 来的正是时候。

原文链接：