Firebase真的像它看起来的那样吗？

不要误会我的意思，我喜欢Firebase - ，但是所有与开发相关的东西，总有好的一面和坏的一面，也有一些恼人的地方，没有人真正想要谈论的。

什么是Firebase？它是谷歌的一体式云服务，包装整齐，提供给那些只想快速启动和运行的开发人员。无需担心资源调配或弹性云结构。你所要做的就是把它连接到你的前端和中提琴上！一切都很正常。

虽然这对于快速成型非常有用，但如果您不小心，成本管理可能会失控。

就我个人而言，在过去的两年里，我一直在与Firebase合作，在不同的产品复杂程度上。在过去的两年中，我发现了关于该平台的一些有趣的事情，特别是关于如何思考以及它对于创建生产就绪的应用程序意味着什么。

不再赘述，这里是Firebase的好的、坏的和恼人的部分-特别是Cloud Firestore。

如果您想要在瞬间从无到有地创建一些东西，那么FireBase是非常棒的，这使得它非常适合快速原型制作。如果你已经掌握了你想要做什么的基本要领，并且需要一个可以连接的完全配置的后端，那么FireBase可以成为你的首选服务。

作为谷歌的一款产品，这意味着它完全集成到了其生态系统内的其他服务中。这包括Google Drive产品-具体地说就是Google Sheets。

在Google Sheet中，您可以创建可以连接到Firebase数据库的自定义脚本。从这里，您可以将数据直接导入到Firebase中，在正确的级别完全格式化，并使用正确的密钥对值集。

如果您有一组模拟数据，这些数据是从另一个非基于开发的部门(如财务、商业或营销)生成的，或者您只需要创建一些功能齐全的东西，以便在短时间内向老板展示，那么这个工具就会派上用场。

它还允许您将您的数据需求委托给其他人，并使将数据集迁移到新应用程序的过程变得更快。能够以部门固有的格式修改和处理数据还可以加快沟通和了解数据如何工作的过程。

或者，您可能在后端技术方面不是很熟练，或者缺乏从头开始创建整个后端集成系统的时间或资源。FireBase是一个很好的解决方案，它弥补了您的技术弱点，这样您就可以专注于通过您的前端提供用户体验。

简而言之，Firebase速度快、自举轻便，并且大部分都集成了您需要的部分。它不仅仅是一个数据库。它是一个静态文件托管平台，一个微服务后端，也是一个随时可用的数据库。

当您从头开始工作时，FireBase工作得非常好。处理遗留问题并在不同类型的项目之间进行交叉集成可能是一个困难的过程。

您输入的数据在Firebase中“卡住”，除非您编写一个函数来导出整个数据集。如果没有某种编程干预，就不会克隆或创建具有相同数据的镜像数据库。

当您的数据集很大且结构不佳时，克隆数据库可能是一项代价高昂的工作。为什么？因为FireBase根据读写收费。如果您的数据没有以最有效的方式结构化，可能会导致账单加倍(一个账单用于读取一个数据库，另一个账单用于写入您的克隆镜像)。

虽然只为您使用的东西付费可能是一种额外的好处，但如果适当地利用和利用，如果成本管理不是您思考过程的一部分，那么它也可能导致您的应用程序的崩溃。

虽然FireBase启动起来可能又快又容易，但您仍然需要考虑数据的外观以及数据的去向。当页面的数据请求导致对Firebase数据库的50个读取请求时，不难发现自己突然增加了大量成本。

这怎麽可能？想象一下购物车页面-您有购物车详细信息、各个产品线、用户信息、辅助详细信息、追加销售、交叉销售、促销，以及任何可能放在购物车结账页面中的内容。这份清单已经列出了七件事。现在设想一位顾客在购物车中添加了三个以上的商品。您的数据需求已经开始攀升。

许多开发人员选择Firebase的问题在于，我们倾向于以SQL的思维方式来组织和查询数据。然而，这可能是你的应用程序的失败，因为当涉及到根据请求而不是按小时收费时，同样的概念和结构应用程序就不起作用了。

当谈到Firebase时，许多开发人员发现自己通过创建的数据和前端代码被锁定在这项服务中。

虽然数据可以(有偿)导出，但是创建与调用和处理Firebase的过程分离的前端代码并没有得到足够广泛的讨论。

这可能会导致许多开发人员滑向与数据库本身耦合过于紧密的滑坡路。尽管Firebase使从头启动变得很容易，但仍然需要对应用程序的架构进行前瞻性思考。

老实说，无论您从事哪种类型的项目，前端架构都是必需的。然而，我们中的许多人确实养成了只做东西的习惯，因为我们能做到。在这些情况下，清理和组织通常是最后的想法。

要将Firebase数据库与前端应用程序分离，您需要创建一个额外的层来将数据服务与UI分开。大多数情况下，我只使用适配器或网桥模式，具体取决于情况、预测的未来需求和潜在方向。

作为免责声明，我与Firebase没有任何关联。这篇文章是从该服务的用户的角度出发的，也是我在使用该服务的两年时间里为各种项目所发现的。

Firebase的主要好处是，它消除了作为全栈开发人员所带来的一层复杂性。在某种程度上，它欺骗了完整堆栈标签，并将设置服务器、后端和数据库的基本任务委托给其他人。

这不一定是件坏事。有时，您只想坚持在前端工作，而不是纠结于数据和编写API。FireBase对GraphQL的支持还通过单一界面和标准化的数据检索方法简化了工作。

FireBase的重大垮台也是一项额外的额外福利。在一定程度上，这是因为服务的强弱取决于开发人员如何使用它。虽然基于SQL的数据库是按小时收费的，但Firebase的按使用付费模式可能会导致懒惰的数据结构，如果您的应用程序是面向公众的并迅速传播，则会导致指数级的成本。例如，这家创业公司在72小时内就收到了3万美元的账单。没人想要那样。

虽然Firebase的潜在成本可能看起来是压倒性的和危险的，但它不应该让你望而却步。相反，它应该成为一个警示故事，告诉你要密切关注数据的结构。

还应该注意的是，Firebase并不是您数据需求的最终也是唯一的解决方案。在过去，我更多地将其用作与其他类型的数据库的混合解决方案来存储和管理重要的主数据集。

FireBase适用于瞬态和持久性数据，其中的结构需要灵活多变才能与不断变化的需求保持一致。

我仍然喜欢它，即使它有不好的地方。为什么？因为Firebase的坏处是可控的，我仍然可以直接影响和减轻它的影响。Firebase在某些方面比SQL做得更好(SQL需要单独的后端作为接口)，而且该服务附带了一套自己的预集成，这使得开发流程移动得更快。

火力基地还不错。虽然它不完全是完美的服务，但它做到了它所宣传的-提供了一个平台，让你可以用移动优先的方法快速创建应用程序。