fcm和firebase_Firebase：伟大的，丑陋的和丑陋的-CSDN博客

fcm和firebase

by Pier Bover

通过Pier Bover

Firebase：伟大的，丑陋的和丑陋的 (Firebase: the great, the meh, and the ugly)

We jumped right into Firebase when Google announced it at Google I/O in May 2016.

当Google于2016年5月在Google I / O上宣布它时，我们立即跳入了Firebase。

We were starting a single-page React application that needed to work on mobile via Cordova, and desktop via Electron. So Firebase seemed like a magical solution for us.

我们正在启动一个单页React应用程序，该应用程序需要通过Cordova在移动设备上以及通过Electron在桌面上工作。因此，Firebase对我们来说似乎是一个神奇的解决方案。

Now, after 7 months of working with Firebase almost daily, I’m ready to share our experience with it.

现在，在几乎每天使用Firebase 7个月之后，我准备分享我们的经验。

最棒的 (The Great)

实时数据 (Realtime data)

Yep, that’s awesome. With a bit of plumbing and some data binding sorcery you can connect your views with your data and they magically change when the data changes.

是的，太棒了。通过使用一些管道和一些数据绑定魔术，您可以将视图与数据连接起来，并且当数据更改时它们会神奇地更改。

In our experience performance was consistently great, although Firebase is designed with millions of users in mind so we didn’t even scratch the surface of the beast.

根据我们的经验，尽管Firebase的设计考虑了数百万用户，但性能始终如一，因此我们甚至都没有刮过野兽的表面。

Our users are still impressed by how fast everything runs.

我们的用户对一切运行的速度仍然印象深刻。

类固醇的静态托管 (Static hosting on steroids)

Firebase hosting comes with free CDN and SSL — all running on the Google Cloud platform. This means you shouldn’t have any problems serving files to any number of users all over the globe.

Firebase托管随附免费的CDN和SSL，它们都在Google Cloud平台上运行。这意味着向全球任何数量的用户提供文件都不会有问题。

If you’re looking for zero-configuration hosting for your next single-page app or static website, I’d really consider Firebase as an option, even if you don’t use any of Google’s other services.

如果您正在寻找下一个单页应用程序或静态网站的零配置托管服务，即使您不使用Google的任何其他服务，我也确实会考虑选择Firebase。

超级大国 (Super powers)

Firebase also provides you with a number of services and SDKs that are super easy to integrate such as:

Firebase还为您提供了许多易于集成的服务和SDK，例如：

OAuth authentication
OAuth验证
File storage
档案储存
Database backups
数据库备份
Automagical scaling
自动缩放
CLI for deploying and other duties
用于部署和其他职责的CLI
Free tier
免费套餐

h (The Meh)

控制台 (The console)

It’s pretty and it allows you to do a number of things, but it’s not that useful.

它很漂亮，它可以让您做很多事情，但没有那么有用。

The database manager is really a glorified JSON editor. Great for what it is, but it’s not the full fledged solution I was expecting it to be. If you come from WorkBench, Postico, Mongotron, or even PHPMyAdmin, this will come as a nice toy.

数据库管理器实际上是一个出色的JSON编辑器。很棒，但它并不是我期望的完整解决方案。如果您来自WorkBench，Postico，Mongotron甚至PHPMyAdmin，这将是一个不错的玩具。

Another very limiting aspect of the console is the lack of detailed logs or analytics. Considering it’s data-obsessed-Google we are talking about this seems bizarre. Sure you get a nice graph for usage of the database, but there is no way to know how many times a file has been downloaded from storage unless you implement a solution yourself.

控制台的另一个非常有限的方面是缺少详细的日志或分析。考虑到它是数据痴迷的Google，我们谈论这似乎很奇怪。当然，您会获得一个很好的数据库使用情况图表，但是除非您自己实施解决方案，否则无法知道从存储中下载文件的次数。

无服务器？ (Serverless?)

Firebase is static hosting + API, nothing more. This limitation is not the end of the world. You can easily solve this by using a Node.js server as another client of Firebase, which you will most probably need for many common tasks such as creating thumbnails, sending emails to your users, etc.

Firebase是静态托管+ API，仅此而已。这个限制不是世界末日。您可以通过将Node.js服务器用作Firebase的另一个客户端来轻松解决此问题，这很可能需要执行许多常见任务，例如创建缩略图，向用户发送电子邮件等。

Apparently it will be possible to use Google Cloud Functions (still in Alpha) with Firebase but who knows when. Maybe this will be announced at Google I/O 2017.

显然可以在Firebase中使用Google Cloud Functions (仍在Alpha中)，但谁知道什么时候。也许这将在2017年Google I / O上宣布。

( Edit March 2017: Firebase just announced Google Cloud Functions for Firebase )

(编辑2017年3月 ：Firebase刚刚宣布了适用于Firebase的Google Cloud Functions )

(Edit May 2018: Check my review of Firebase Cloud Functions)

( 编辑2018年5月 ：检查我对Firebase Cloud Functions的评论 )

定义安全规则 (Defining security rules)

Firebase uses a JSON file with Javascript code in strings to define rules over the database and storage.

Firebase使用JSON文件和字符串形式的JSON文件来定义数据库和存储上的规则。

{  "rules": {    "users": {      "$uid": {        ".write": "$uid === auth.uid"      }    }  }}

This is not as bad as it sounds since you can use Bolt to make this process less painful. Although, even when using Bolt, once you go beyond a simple few dozen rules this file becomes unmaintainable Italian Food™.

这并不像听起来那样糟糕，因为您可以使用Bolt减轻此过程的痛苦。虽然，即使使用Bolt，一旦您超越了简单的几十条规则，该文件就会变得难以维护的Italian Food™。

Services like Dream Factory and Graph Cool give you a proper tool to do that without losing your sanity.

诸如Dream Factory和Graph Cool之类的服务为您提供了一个合适的工具，而又不会失去理智。

专有技术 (Proprietary tech)

When Facebook decided to shut down Parse, many projects found themselves in a difficult position. I honestly doubt this is going to happen to Firebase, but I can understand the reluctance to couple your tech stack with a third party platform-as-a-service.

当Facebook决定关闭Parse时，许多项目陷入困境。老实说，我怀疑Firebase是否会发生这种情况，但我可以理解，您不愿意将您的技术堆栈与第三方平台即服务结合在一起。

无法在本地发展 (No way to develop locally)

If you travel frequently or live in a country with poor connectivity consider that you can’t work with a local installation. You can’t just use Docker or Node and start your API.

如果您经常旅行或居住在连通性较差的国家/地区，请考虑使用本地安装。您不能只使用Docker或Node并启动API。

丑陋的 (The ugly)

受限的Javascript SDK (Limited Javascript SDK)

There are a number of features in Firebase that are only implemented in their iOS and Android SDKs.

Firebase中有许多功能仅在其iOS和Android SDK中实现。

The most glaring one is the lack of offline persistence when working with Javascript. Your web, hybrid, or ReactNative application will continue working if the device loses connectivity momentarily. But once you close the application or tab, your data will be gone. It’s up to you to implement a cache with persistence. This can really be a serious endeavor, especially on mobile.

最明显的原因是使用Javascript时缺少脱机持久性。如果设备暂时失去连接，您的Web，混合或ReactNative应用程序将继续运行。但是一旦关闭应用程序或选项卡，您的数据就会消失。由您来实现具有持久性的缓存是您的责任。这确实是一项严肃的工作，尤其是在移动设备上。

The Javascript SDK doesn’t even have a way to cache data (not sure about iOS or Android). If you load /products and then need that data again later you will have to reload it unless you manually keep a connection in the background. It’s not hard to implement this, but again, why doesn’t Firebase provide a magical way to do that?

Javascript SDK甚至没有缓存数据的方式(不确定iOS或Android)。如果您加载/products ，然后在以后再次需要该数据，则必须重新加载它，除非您在后台手动保持连接。实现这一点并不难，但是，Firebase为什么不提供一种神奇的方法来实现这一点呢？

无法正确查询数据 (No way to query your data properly)

You can do some very basic filtering and pagination, but other than that you are on your own.

您可以执行一些非常基本的过滤和分页，但除此之外，您可以自己进行。

Really? Google is providing a data service with no searching or filtering capabilities?

真？ Google提供的数据服务没有搜索或过滤功能？

Yeah. Really.

是的真。

If you want to implement search functionality, you will have to either download all the data and do it in the client, use a server like I described previously, or implement a third party service like Elastic.

如果要实现搜索功能，则必须下载所有数据并在客户端中进行处理，使用如前所述的服务器，或实现诸如Elastic的第三方服务。

Firebase’s developers have said that this is by design, so they can assure high performance. OK. But why not let us users decide if we can afford to pay the performance price for our use case?

Firebase的开发人员表示，这是设计使然，因此他们可以确保高性能。好。但是，为什么不让我们的用户决定我们是否有能力为用例支付性能价格呢？

Yeah, and forget about doing joins or anything remotely fancy with your data. Which brings me to…

是的，而不必进行联接或对数据进行任何远程处理。带我去...

哑数据建模 (Dumb data modelling)

Dealing with relations with NoSQL is hard, dealing with relations with Firebase is pain in the ass. - Baptiste Jamin

处理与NoSQL的关系很困难，处理与Firebase的关系很麻烦。 - 巴蒂斯特·贾明 ( Baptiste Jamin)

What he said.

他说什么。

The Firebase database is basically just one huge JSON file. There’s no way to declare one to many or many to many relationships. In practice this means that you’ll end up duplicating your data all over the place.

Firebase数据库基本上只是一个巨大的JSON文件。没有办法声明一对多或多对多关系。实际上，这意味着您最终将在各处复制数据。

This doesn’t seem so bad at first. After all, it’s convenient to put the name of the user in a chat message, no?

乍一看似乎还不错。毕竟，将用户名放在聊天消息中很方便，不是吗？

{ “author”:”Pepito Flores”, “message”:”I want a taco!”, “time”: 1484269756951}

The problem comes when you have to actually edit Pepito’s name since you will have to modify it everywhere you have used it and not only in /users.

当你有实际编辑Pepito的名字，因为你将不得不到处修改它，你使用它，而不是只在问题出现/users 。

Telling your users that they can’t edit their name is not usually a viable option, so:

告诉用户他们无法编辑其名称通常不是可行的选择，因此：

Your client code for writing and editing data to Firebase will become in many cases Italian Food™.
在许多情况下，您用于向Firebase写入和编辑数据的客户代码将成为Italian Food™。
Documenting where you have duplicated your data will be difficult to say the least.
至少很难说出在哪里记录了数据的重复记录。

Also since many NoSQL databases like MongoDB or RethinkDB have found ways around this problem, I find it difficult to believe that Google can’t solve this with at least reasonable performance.

同样，由于许多NoSQL数据库(如MongoDB或RethinkDB)已经找到解决此问题的方法，因此我很难相信Google至少不能以合理的性能来解决此问题。

TL; DR (TL;DR)

Firebase is awesome for simple projects or developing small features that require realtime data. For example a chat or a notification system. Those are the impressive 30 min demos you see on YouTube. It also works really well if your data are streams of things with a simple structure such as a service for an online multiplayer game.

Firebase非常适合用于简单项目或开发需要实时数据的小型功能。例如聊天或通知系统。这些是您在YouTube上看到的令人印象深刻的30分钟演示。如果您的数据是具有简单结构的事物流(例如，用于在线多人游戏的服务)，它也将非常有效。

Anything with more complex data requirement becomes difficult or even impossible with Firebase. Regular run of the mill database queries are in most cases more valuable than realtime data, and as impressive as seeing stuff changing is, you probably don’t need any of it.

使用Firebase，任何具有更复杂数据要求的事情都会变得困难甚至无法实现。在大多数情况下，常规运行的工厂数据库查询比实时数据更有价值，并且看到事物的变化令人印象深刻，您可能不需要任何信息。

Like everything, pick the right tool for the job.

像所有事物一样，选择适合工作的工具。

附录：Firebase需要具备哪些出色功能 (Addendum: what Firebase needs to be awesome)

Real querying capabilities. Search, joins, the whole enchilada.
真正的查询功能。搜索，加入整个辣酱玉米饼馅。
Some sort of references likes MongoDB or RethinkDB.
诸如MongoDB或RethinkDB之类的引用。
Real offline persistence with Javascript.
使用Javascript实现真正的离线持久性。
Give me moar analytics.
给我moar分析。
A cache API.
缓存API。

That is all.

就这些。

附录2：摩尔信息 (Addendum 2: moar info)

If you are reading this you might be evaluating Firebase as a developer or CTO. Here are some other articles that could help you decide whether Firebase might work for you, and whether it’s worth investing extra dev time for evaluation.

如果您正在阅读本文，则可能是将Firebase评估为开发人员或CTO。以下是一些其他文章，可以帮助您确定Firebase是否适合您，是否值得投入更多的开发时间进行评估。

Firebase: The Good, Bad, and the Ugly - RaizException - Raizlabs Developer BlogAs part of our work as software developers at Raizlabs, we are constantly evaluating the latest development tools used…www.raizlabs.com Reasons Not To Use FirebaseBuilding real-time applications is today standard. At Crisp, we used Firebase in production over 9 month, starting from…crisp.im

Firebase：好的，坏的和丑陋的-RaizException-Raizlabs开发人员博客 作为 Raizlabs 软件开发人员的一部分，我们不断评估使用的最新开发工具…… www.raizlabs.com 不使用Firebase Building的 原因 时间应用程序已成为当今的标准。 从 Crissis.im 开始，在Crisp中，我们在9个月的生产中使用了Firebase。