99re6这里只有精品地址

大家好，99re6这里只有精品地址相信很多的网友都不是很明白，包括我们弃用 Firebase 了也是一样，不过没有关系，接下来就来为大家分享关于99re6这里只有精品地址和我们弃用 Firebase 了的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！

作者|JohnConsidine

译者|平川

策划|刘燕

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

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

Firebase：好的地方

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

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

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

使用Firestore，许多客户端状态管理方面的挑战都不复存在，特别是与数据新鲜度有关的问题。免费就可拥有的实时体验。Firestore的文档/集合架构：它迫使人们仔细考虑数据建模。它还反映了一个直观的导航方案。Firestore中的关系数据也是如此。与MongoDB不同，它不可能远程执行任何类似于SQL连接的操作。因此，开发人员必须接受NoSQL的精神，提前分发关系数据。Firebase套件可以帮助我们快速构建可扩展的原型，处理来自客户端的数据连接，在发布到生产环境之前强化安全规则，并对敏感逻辑使用FirebaseFunctions。云Firestore安全规则写起来很有趣，在考虑客户端-服务器安全方面，这是一个可靠的模型。开箱即用的身份验证很不错。（不过，在我们看来，其内置的Firebase邮件验证体验很糟糕）。实际上，我们发现，在CI/CD方面，FirebaseHosting比AWSS3+Cloudfront更简单，因为它提供了一个简单的命令可以对存储库做这方面的设置。Firebase：不那么好的地方

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

Firebase要求使用谷歌/GSuite登录——我们喜欢分散我们的供应商和服务。FirebaseHosting不提供细粒度的文件控制：你可以部署整个应用程序，也可以什么都不部署。也许不常见，但我们在静态页面生成和调试CDN问题上遇到了限制。Firestore索引的创建速度非常缓慢，而且不优雅，比创建同等的Algolia索引花费的时间要长得多。由于是闭源的，你不能默认以为Firebase始终存在（像Parse一样），依赖于特定的API版本也不可靠。因此，你也不能真正地在本地运行Firebase。当然，也有Firebase模拟器，但它们很慢，也很难调试，而且普遍存在不足；经常会在负载不是很大的情况下出现意料之外的失败，而你可能期望有一个能够承受足够负载的、健壮的本地环境。FirebaseCLI限制相当严格：

对于像启用Firestore这么简单的事情，你也只能通过仪表板完成，而不能通过命令行。

firebaselogin:ci有意禁止传递认证密钥。我喜欢执行firebaselogin:ci|xargs-I{}ghsecretsetFIREBASE_TOKEN--body="{}"，但唉，其前后都还有其他的命令。（见下面我们使用的一种丑陋的变通方案）附注：说到FirebaseCLI的限制，下面是两个我们经常使用的解决方案，或许对你有用。

提取机器可读的CItoken

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

citokenRaw=$(firebaselogin:ci)ncitoken=$(echo"$citokenRaw"|tail-n3|head-n1)n将Web配置加入.env文件

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

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

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

不祥之兆

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

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

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

如果这可以定制，那对我来说会是一种帮助。

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

我无法在Firebase仪表板上下载这个文件。这不符合直觉，“打开”竟然不让我下载。

直接从GoogleCloudConsole下载。

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

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

近期CloudFunction部署的速率限制

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

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

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

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

使用单个基于事件名称调用条件逻辑（如使用事件分派器）的CloudFunction。那看起来像是一个名为dispatcherFunction的函数，根据eventName切换到相应内部函数的调用。逐步形成一种约定，其中每个CloudFunction都对应于它自己的文件。在CI代码中，过滤掉未更改的文件，并部署与已更改的文件相对应的函数。不用说，这两种变通方法都有很多需要改进的地方。将路由逻辑塞进端点牺牲了可读性和HTTP层缓存，而且这种脚手架方法无助于现有的大型项目。GCP偏向之二

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

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

根据CloudFunction部署文档：Firebase错误只能在GoogleCloud上解决。

Supabase

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

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

声明：本文为InfoQ翻译，未经许可禁止转载。

原文链接：

https://koptional.com/article/why-we%E2%80%99re-moving-away-from-firebase

END，本文到此结束，如果可以帮助到大家，还望关注本站哦！