firebase_Firebase真的像它看起来那样很棒

firebase

Don’t get me wrong, I like Firebase — but with everything dev related, there’s always a good and bad side, with a pinch of annoying that no one really wants to talk about.

不要误会我的意思，我喜欢Firebase，但与开发人员相关的所有方面，总有好事与坏的一面，令人讨厌的是，没有人真正想谈论。

What is Firebase? It’s Google’s all-in-one cloud service, neatly packaged and delivered to developers who just want something up and running quickly. No need to worry about provisioning or elastic cloud structures. All you have to do is connect it to your front end and viola! everything just works.

什么是Firebase？ 这是Google的多合一云服务，整齐打包并交付给只希望快速启动并运行的开发人员。 无需担心配置或弹性云结构。 您所要做的就是将其连接到您的前端和中提琴！ 一切正常。

While this is great for rapid prototyping, cost management can get out of hand if you’re not careful.

虽然这是格雷亚吨快速成型，成本管理失控，如果你不小心。

Personally, I’ve been working with Firebase for the past two years, at different product complexity levels. In these past two years, I’ve discovered interesting things about the platform, especially about how to think and what it can mean for creating a production-ready application.

就个人而言，过去两年来我一直在Firebase工作，产品级别不同。 在过去的两年中，我发现了有关该平台的有趣内容，特别是关于如何思考以及对创建可用于生产环境的应用程序意味着什么。

Without further ado, here’s the good, the bad, and the annoying parts of Firebase — specifically Cloud Firestore.

事不宜迟，这里是Firebase的好，坏和烦人的部分，尤其是Cloud Firestore。

Firebase的优点 (The good parts of Firebase)

Firebase is fantastic if you want to create something out of nothing in a flash, making it great for rapid prototyping. If you’ve got the general gist of what you want to do and need a fully configured backend you can connect to, then Firebase can be your go-to service.

如果您想一瞬间创建出一些东西，那么Firebase就是很棒的选择，它非常适合快速原型制作。 如果您已了解要执行的操作的基本要点，并且需要可以连接的完全配置的后端，则Firebase可以成为您的首选服务。

Being a Google product, it means that it’s fully integrated into other services within its ecosystem. This includes Google drive products — specifically Google Sheets.

作为Google产品，这意味着它已完全集成到其生态系统内的其他服务中。 这包括Google驱动器产品，特别是Google表格。

In Google Sheets, you have the ability to create custom scripts that can connect to your Firebase database. From here, you can import the data straight into Firebase, fully formatted at the right levels, and with the correct set of key-pair values.

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

This can come in handy when you have a set of mock data, generated from another non-dev based department such as finance, commercial, or marketing, or you just need to create something that’s fully functional to show the boss in a short amount of time.

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

It also lets you delegate your data needs over to someone else, and make the process of migrating datasets to new applications much faster. Being able to modify and deal with data in formats that native to the department can also speed up communication and the process of understanding how the data works.

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

Alternatively, you might not be highly skilled in backend technologies or lack the time or resources to create an entire backend integration system from scratch. Firebase makes a great solution by bolstering up your technical weaknesses so you can focus on delivering the user experience with your frontends.

另外，您可能不擅长后端技术，或者没有时间或资源来从头创建整个后端集成系统。 Firebase通过弥补您的技术弱点而成为一个很好的解决方案，因此您可以专注于通过前端交付用户体验。

In short, Firebase is fast, lightweight to bootstrap, and has mostly integrated parts you need. It’s more than just a database. It’s a static file hosting platform, a microservice backend, as well as ready to go database.

简而言之，Firebase快速，轻便地引导，并且具有所需的大部分集成部件。 它不仅仅是一个数据库。 这是一个静态文件托管平台，一个微服务后端以及随时可用的数据库。

Firebase的坏处 (The bad parts of Firebase)

Firebase works really well when you’re working from scratch. Working with legacies and cross integrating between different types of projects can be a difficult process.

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

The data you put in is ‘stuck’ inside Firebase unless you write a function to export the entire dataset. There’s no cloning or creating mirror databases with the same data, without some sort of programmatic intervention.

除非您编写用于导出整个数据集的函数，否则您放入的数据将“卡在” Firebase中。 没有某种程序干预，就不会克隆或创建具有相同数据的镜像数据库。

When your dataset is small, this isn’t too bad.

当您的数据集很小时，这还不错。

When your dataset is large and has bad structures, cloning a database can be a costly exercise. Why? Because Firebase charges based on reads and writes. If your data is not structured in the most efficient manner, it can result in a doubling the bill (one bill for reading one database and another for writing to your clone mirror).

当您的数据集很大且结构不良时，克隆数据库可能是一项代价高昂的工作。 为什么？ 因为Firebase会根据读取和写入进行收费。 如果未以最有效的方式来构造数据，则可能导致帐单增加一倍(一个帐单用于读取一个数据库，另一个帐单用于写入克隆镜像)。

While paying for only what you use can be a perk, when leveraged and utilized properly, it can also be your application’s downfall if cost management is not part of your thinking process.

虽然仅支付您使用的费用可能是一种福利，但是如果合理利用和利用，则如果成本管理不是您的思考过程的一部分，这也可能是应用程序的失败。

Firebase might be quick and easy to boot up, you still need to think about how your data is going to look and where it’s going to go. It’s not hard to suddenly find yourself racking up massive costs when a page’s data request results in 50 read requests to the Firebase database.

Firebase可以快速轻松地启动，您仍然需要考虑数据的外观以及数据的去向。 当页面的数据请求导致对Firebase数据库的50个读取请求时，突然发现自己付出了不菲的代价，这并不难。

How is this possible? Imagine a cart page — you have your cart details, your individual product lines, your user information, your ancillary details, upsells, cross-sells, promotions, and whatever else you can potentially put in a cart checkout page. This list already has seven things listed. Now imagine a customer with more than three items added to the cart. Your data requirements are already starting to creep up.

这怎么可能？ 想象一下购物车页面-您在购物车结帐页面中拥有购物车详细信息，单个产品系列，用户信息，辅助详细信息，加价销售，交叉销售，促销以及其他任何可能放置的内容。 此列表已经列出了七件事。 现在，假设有一个客户将超过三个商品添加到购物车。 您的数据要求已经开始攀升。

The issue with many devs picking up Firebase is that we tend to think with a SQL mentality of structuring and querying data. However, this can be your application's downfall because when it comes to getting charged based on requests rather than the hour, the same applications of concepts and structuring doesn’t work.

许多开发人员选择Firebase的问题在于，我们倾向于以结构化和查询数据SQL思维来思考。 但是，这可能是您的应用程序的失败原因，因为要基于请求而不是按小时收费，概念和结构的相同应用程序将无法正常工作。

Firebase令人讨厌的部分 (The annoying parts of Firebase)

When it comes to Firebase, many developers find themselves locked into the service through the data and the frontend code created.

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

While data can be exported (at a price), creating frontend code that’s separated from the process of calling and dealing with Firebase is something that’s not discussed widely enough.

尽管可以导出数据(收费)，但创建与调用和处理Firebase流程分开的前端代码的问题还没有得到足够广泛的讨论。

This can lead many devs down the slippery slope of becoming too tightly coupled to the database itself. Although Firebase makes it easy to boot up something from scratch, forward-thinking about your app’s architecture is still required.

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

To be honest, front end architecture is needed regardless of what kind of project you’re working on. However, a lot of us do fall into the habit of just making things because we can. Cleaning up and structuring is often a last port of thought in these situations.

老实说，无论您从事哪种项目，都需要前端体系结构。 但是，我们中的许多人确实养成了仅仅制造东西的习惯，因为我们可以做到。 在这些情况下，清理和结构化通常是最后的想法。

To decouple your Firebase database from your frontend application, you’ll need to create an extra layer that keeps data services separated from your UI. Most of the time, I just use an adapter or bridge pattern, depending on the situation, predicted future requirements, and potential direction.

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

权衡一切 (Weighing it all up)

As a disclaimer, I’m not affiliated with FIrebase in any way. This is written from the perspective of a user of the service and what I’ve discovered so far in the two years of working with it for various projects.

作为免责声明，我不以任何方式隶属于FIrebase。 本文是从服务用户的角度编写的，而到目前为止，我在为各种项目使用它的两年中已经发现了这些内容。

The major perk of Firebase is that it takes away a layer of complication that comes with working as a fullstack developer. In a way, it’s cheating the fullstack tag and delegating the foundational tasks of setting up servers, backends, and databases to someone else.

Firebase的主要优势在于，它消除了作为全栈开发人员而带来的复杂性。 在某种程度上，它欺骗了fullstack标记，并将将服务器，后端和数据库的基本任务委托给其他人。

This isn’t necessarily a bad thing. Sometimes, you just want to stick to working on the frontend rather than wrangle with data and writing APIs. Firebase’s support of GraphQL also makes life easier through the single interface and standardized methodology of retrieving data.

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

Firebase’s major downfall also doubles up as a perk. In part, it’s because the strength or weakness of the service is defined by how the developer uses it. While SQL based databases are charged by the hour, Firebase’s pay-per-use model can result in lazy data structures, leading to exponential costs if your application is public-facing and goes viral. This startup, for example, ended up with a $30k bill in 72 hours. No one wants that.

Firebase的重大故障也使您振作起来。 在某种程度上，这是因为服务的强项或弱项是由开发人员使用它的方式定义的。 虽然基于SQL的数据库按小时收费，但Firebase的按使用付费模型可能会导致数据结构变懒，如果您的应用程序面向公众并且流行，则会导致成倍的成本。 举例来说，这家初创公司在72个小时内结账了3万美元 。 没有人想要。

While the potential cost of Firebase can seem overwhelming and dangerous, it shouldn’t deter you. Rather, it should act as a cautionary tale about keeping an eye on how your structure your data.

尽管Firebase的潜在成本似乎是巨大的和危险的，但它并不能阻止您。 相反，它应该作为一个警惕的故事，以密切关注数据的结构。

It should also be noted that Firebase isn’t expected to the final and only solution to your data needs. In the past, I’ve used it more as a hybrid solution with other types of databases to store and manage important master sets of data.

还应注意，Firebase不能最终满足您的数据需求。 过去，我将它更多地用作与其他类型的数据库的混合解决方案，以存储和管理重要的数据主集。

Firebase is good for transient and persistent data, where the structure needs to be flexible and changeable to be in-step with constantly changing demands.

Firebase适用于瞬态和持久数据，其中结构需要灵活且可更改，以与不断变化的需求保持同步。

So what’s the final verdict on Firebase after two years?

那么，两年后对Firebase的最终裁决是什么？

I still like it, even with its bad parts. Why? Because the bad parts of Firebase are manageable and I can still directly impact and mitigate its effects. There are things that Firebase does better than SQL (which requires a separate backend to act as the interface), and the service comes with its own set of pre-integration that makes the development flow move faster.

我仍然喜欢它，即使它有坏的部分。 为什么？ 由于Firebase的不良部分是可管理的，因此我仍然可以直接影响和减轻其影响。 Firebase在某些方面比SQL更好(后者需要一个单独的后端作为接口)，并且该服务带有其自己的一组预集成，从而使开发流程移动得更快。

Firebase is not bad. While it’s not exactly the perfect service, it does what it advertises — provide a platform that lets you rapidly create applications with a mobile-first approach.

Firebase不错。 虽然它并不是完美的服务，但它确实做了广告—提供了一个平台，让您可以使用移动优先的方法快速创建应用程序。

翻译自: https://medium.com/madhash/is-firebase-really-as-awesome-as-it-seems-8bced89ecebb

firebase