firebase使用_这就是我希望在开始使用Firebase之前所要知道的

firebase使用

by Nikhil Sridhar

由Nikhil Sridhar

这就是我希望在开始使用Firebase之前所要知道的 (Here’s what I wish I knew before I started using Firebase)

选择Cloud Firestore作为数据库之前应考虑的优缺点列表 (A list of advantages and drawbacks you should consider before choosing Cloud Firestore as your database)

Over the last few years, Firebase has grown as an increasingly popular backend solution. Especially after the release of Cloud Firestore. Firestore is a flexible cloud database with expressive queries and real-time updates. After developing my first application with Cloud Firestore, I organized a list of advantages and drawbacks. This list will help you choose if Firestore is the database for you.

在过去的几年中，Firebase已经成为越来越受欢迎的后端解决方案。 尤其是在Cloud Firestore发布之后。 Firestore是一个灵活的云数据库，具有表达性查询和实时更新。 在使用Cloud Firestore开发了我的第一个应用程序之后，我整理了一系列优缺点。 此列表将帮助您选择Firestore是否适合您。

Before I begin, it is imperative that you understand Cloud Firestore’s data model. Firestore stores data in documents, organized into collections. Each document contains a set of key-value pairs. Cloud Firestore is optimized for storing large collections of small documents. All documents must be stored in collections. Documents can contain sub-collections and nested objects. Both of which can include primitive fields like strings or complex objects like lists.

在开始之前，您必须了解Cloud Firestore的数据模型。 Firestore将数据存储在文档中，并组织为集合。 每个 文档 包含一组键值对 。 Cloud Firestore经过优化，可存储大量小文件。 所有文档必须存储在 集合中 。 文档可以包含子集合和嵌套对象。 两者都可以包括诸如字符串之类的原始字段或诸如列表之类的复杂对象 。

Now that you understand the basics, here is a list of items in Cloud Firestore which can make or break your application.

现在，您已经了解了基础知识，这是Cloud Firestore中可以创建或破坏您的应用程序的项目的列表。

优势1：事务和批量写入 (Advantage 1: Transactions and Batched Writes)

Error handling can be one of the most tedious tasks when it comes to reading from and writing to a database. In some situations, if an error occurs while reading from or writing to one location in the database, you might want to cancel the entire operation. This is where batched writes and transactions come in.

在读取和写入数据库时​​，错误处理可能是最繁琐的任务之一。 在某些情况下，如果在读取或写入数据库的一个位置时发生错误，则可能要取消整个操作。 这是批量写入和事务进入的地方。

Batched writes are a set of write operations performed atomically. In a set of atomic operations, either all the operations succeed, or none of them. If your application succeeds in writing data to one document but fails in writing data to another document, none of the writes are performed. An error is thrown.

批量写入是原子执行的一组写入操作。 在一组原子操作中，所有操作要么成功，要么都不成功。 如果您的应用程序成功将数据写入一个文档，但未将数据写入另一文档，则不会执行任何写入操作。 引发错误。

Transactions work similarly. They are more powerful, for they allow you to both read and write to documents in an atomic fashion.

事务工作类似。 它们功能更强大，因为它们允许您以原子方式读取和写入文档。

Batched writes and transactions can be best explained through an example. The easiest being adding friends on a social media platform. When User A adds User B as a friend, you want to write data to both User A’s document and User B’s document to signify that they are friends. However, if either the write to User A’s document or User B’s document fails, you want to undo any changes and throw an error. Batched writes and transactions simplify this process with only a few lines of code.

批处理写入和事务可以通过示例来最好地说明。 最容易的是在社交媒体平台上添加朋友。 当用户A将用户B添加为朋友时，您希望将数据写入用户A的文档和用户B的文档中，以表明他们是朋友。 但是，如果写入用户A的文档或用户B的文档失败，则您要撤消所有更改并引发错误。 批处理写入和事务处理仅需几行代码即可简化此过程。

优势2：邀请 (Advantage 2: Invites)

Firebase Invites is perhaps the most powerful on-boarding technique, especially if your app runs on multiple platforms (iOS, Android, etc.). It allows you to prompt the current user if he would like to invite his friends to your app. However, what’s more is that Firebase actually allows you to create a temporary user for the invited user to provide the current user with the best customer experience.

Firebase Invites可能是最强大的入门技术 ，尤其是当您的应用程序在多个平台(iOS，Android等)上运行时。 它允许您提示当前用户是否想邀请他的朋友加入您的应用。 但是，更重要的是，Firebase实际上允许您为受邀用户创建一个临时用户，以为当前用户提供最佳的客户体验。

For instance, let us say that you are building an app similar to Venmo. This app allows users to track expenses and eventually settle up. User A wants to pay User B, who currently does not have an account. Using Firebase Invites, you could allow User A to invite User B. Then set up a temporary account for User A to track expenses with until User B accepts the invitation and creates his own account. Invites provide app referrals through both email and SMS. It is a great way to acquire new users and keep current users happier than ever before.

例如，假设您正在构建类似于Venmo的应用程序。 该应用程序允许用户跟踪费用并最终解决。 用户A要向当前没有帐户的用户B支付费用。 使用Firebase邀请，您可以允许用户A邀请用户B。然后为用户A设置一个临时帐户来跟踪费用，直到用户B接受邀请并创建自己的帐户为止。 邀请对象通过电子邮件和短信提供应用推荐。 这是获取新用户并保持现有用户幸福感的好方法。

优势3：动态链接 (Advantage 3: Dynamic Links)

Firebase Dynamic Links allows for the best possible user-onboarding experience. These links work cross-platform. They allow you to provide a custom experience within an application once a user opens a certain link. Dynamic Links is best utilized when integrated with Firebase Invites.

Firebase动态链接可提供最佳的用户入门体验。 这些链接跨平台工作。 一旦用户打开某个链接，它们使您能够在应用程序中提供自定义体验 。 与Firebase邀请集成时，最好利用动态链接。

Let us take the example in the previous advantage. User B, who has been invited to your app by User A, now decides he wants to create an account to view any debts he owes to User A. When User B receives the invite via email and clicks on the dynamic link, he will be directed to the AppStore where he will download your app. Then, when he opens the app and begins to register, his email will already be filled in thanks to the information passed by the dynamic link.

让我们以先前的优势为例。 用户B已被用户A邀请到您的应用程序，现在决定他要创建一个帐户来查看他欠用户A的所有债务。当用户B通过电子邮件收到邀请并单击动态链接时，他将定向到AppStore，他将在其中下载您的应用。 然后，当他打开该应用并开始注册时，由于动态链接传递了信息 ，因此他的电子邮件已经被填写。

缺点1：按子集合查询 (Drawback 1: Querying by Sub-collection)

One of the biggest disappointments in Cloud Firestore is the inability to query documents by their sub-collections. For example, let us say you have the following data structure:

Cloud Firestore中最大的失望之一是无法通过文档的子集合来查询文档 。 例如，假设您具有以下数据结构：

collection of users -> user document -> collection of friends ->; friend document -> data regarding that friend (name, email, etc.)

用户集合 ->用户文档 ->朋友集合 -> ; 朋友文档数量 ->有关该朋友的数据(姓名，电子邮件等)

In this structure, it would be impossible to fetch all users who have a friend with a specific name and email. Firebase does eventually plan to offer a solution. For the time being, it seems like the only solution is to replace sub-collections with arrays in which documents can be queried by.

在这种结构中，将不可能获取所有拥有特定名称和电子邮件好友的用户。 Firebase确实确实计划提供解决方案。 目前，似乎唯一的解决方案是用可以查询文档的数组替换子集合 。

Although this fix might seem sufficient, it isn’t. As your application grows, so can the arrays, significantly affecting the read and write document performance.

尽管此修复程序似乎足够，但还不够。 随着应用程序的增长，数组也会增加，从而极大地影响读写文档的性能 。

缺点2：按位置查询 (Drawback 2: Querying by Location)

Depending on your application’s functionality, this could be the biggest flaw of all. Although Cloud Firestore does provide a location data type, it does not allow you to query all documents within a radius of a given location.

根据您应用程序的功能，这可能是最大的缺陷。 尽管Cloud Firestore确实提供了位置数据类型， 但是它不允许您查询给定位置范围内的所有文档 。

Let us consider that you are building an app identical to Uber. When a user logs into the app, you want to fetch all cars within a certain radius of the current user’s location to alert the user if there are any drivers nearby. This task is impossible without the help of third party libraries.

我们认为您正在构建与Uber相同的应用程序。 当用户登录到应用程序时，您希望获取当前用户位置一定半径范围内的所有汽车，以警告该用户附近是否有驾驶员。 没有第三方库的帮助，此任务是不可能的。

Luckily, if you are using the real-time database, Firebase now recommends you use the GeoFire library to query documents by location. However, if you plan to use Cloud Firestore, there is no recommended solution.

幸运的是，如果您使用实时数据库，Firebase现在建议您使用GeoFire库按位置查询文档。 但是，如果您打算使用Cloud Firestore，则没有推荐的解决方案。

Although there are a few libraries which have attempted to solve this problem like GeoFirestore, Firebase has yet to verify them as a reliable source.

尽管有一些库试图解决此问题，例如GeoFirestore ，但Firebase尚未验证它们是否是可靠的来源。

缺点3：全文搜索 (Drawback 3: Full-text Search)

This problem is sure to affect anybody who uses Cloud Firestore, for it does not allow you to query documents by “incomplete text”. This problem can be best illustrated through an example.

这个问题肯定会影响使用Cloud Firestore的任何人，因为它不允许您通过“不完整的文本”查询文档 。 可以通过示例最好地说明此问题。

Let us say your application allows users to friend each other. One user types in “Al” in an attempt to search for his friend “Alex”. You want to fetch all users in the database whose name contains the text “Al” to help the user narrow down his search. This task is not possible through Cloud Firestore alone. Algolia, a third party service, is required to implement full-text search. All documents must be uploaded to Algolia as records. These records can then be queried by incomplete text.

假设您的应用程序允许用户彼此交朋友。 一个用户键入“ Al”以尝试搜索他的朋友“ Alex”。 您希望获取名称中包含文本“ Al”的数据库中的所有用户，以帮助用户缩小搜索范围。 仅通过Cloud Firestore 不可能完成此任务 。 需要第三方服务Algolia来实现全文搜索 。 所有文件都必须作为记录上传到阿尔及利亚。 然后可以通过不完整的文本查询这些记录。

For more tips, please stay tuned and follow me. If you enjoyed this article, feel free to hold down that clap button.

有关更多提示，请随时关注并关注我。 如果您喜欢这篇文章，请随时按住该拍手按钮。

翻译自: https://www.freecodecamp.org/news/heres-what-i-wish-i-knew-before-i-started-using-firebase-9110d393e193/

firebase使用