firebase_Firebase：快速启动应用程序

firebase

Google has invested heavily to make Firebase a full-featured application platform for web. It's dirt cheap to use. It's reliable. It saves up to 50% of your dev time.

Google已投入巨资使Firebase成为功能全面的Web应用程序平台。 使用起来很便宜。 很可靠 它可以节省多达50％的开发时间。

Firebase is all you need... with a few exceptions. Firebase is still missing search functionality, but we can plug that hole with Algolia. Google Cloud Platform provides a few more ancillary services such as DNS, Cloud SQL for reporting data and Bigtable for graph data.

Firebase是您所需要的...除了一些例外。 Firebase仍然缺少搜索功能，但是我们可以用Algolia填补这一漏洞。 Google Cloud Platform提供了更多辅助服务，例如DNS，用于报告数据的Cloud SQL和用于图形数据的Bigtable。

Firebase includes nearly everything I need to build small to medium-sized apps quickly.

Firebase包含了快速构建中小型应用程序所需的几乎所有内容。

快速历史 ( A Quick History )

Firebase was birthed from a Y Combinator company that was acquired by Google in 2014.

Firebase 诞生于2014年被Google收购的Y Combinator公司 。

Firebase is a classic disruptive company. It started as a quick prototyping tool for developers who wanted to move quickly but didn't necessarily need much scale or sophistication.

Firebase是一家经典的破坏性公司 。 它起初是一个快速原型开发工具，适用于想要快速移动但不一定需要大量扩展或复杂性的开发人员。

They've spent the last eight years building capabilities from that original base of passionate freelancers and indie devs, and as a cornerstone of Google Cloud Platform's strategy, Firebase is fighting its way into the larger corporate market.

他们花了八年的时间从​​最初的热情自由职业者和独立开发人员那里构建功能，并且作为Google Cloud Platform战略的基石，Firebase正在争取进入更大的企业市场的途径。

什么是Firebase？ ( What is Firebase? )

Firebase is a suite of managed services that are focused on developer experience over raw power.

Firebase是一套托管服务，着重于开发人员对原始电源的体验。

Firebase handles your authentication, data storage, document storage, serverless functions, and much more.

Firebase可以处理您的身份验证，数据存储，文档存储，无服务器功能等等。

AWS and GCP appeal to large, corporate projects that can take years to ship. Use Firebase when you need to ship yesterday.

AWS和GCP吸引了可能需要数年才能交付的大型公司项目。 如果您需要昨天发货，请使用Firebase。

You may have heard that Firebase is just for startups or prototypes, or that it fails at scale or gets super expensive. Well... things have changed. A lot.

您可能已经听说Firebase仅适用于初创企业或原型，或者大规模失败或变得昂贵。 好吧...情况已经变了。 很多。

一个简单的例子 (A Quick Example)

We have been Twitch streaming here at Scotch and we built a real-time voting app using Firebase. Built in a couple hours, you can see everyone on the Twitch stream voting and seeing the update on screen in real-time: Watch Here

Twitch在Scotch上一直在流媒体播放 ，我们使用Firebase构建了一个实时投票应用程序。 在几个小时内建成后，您可以在Twitch流中看到所有人进行投票，并实时在屏幕上看到更新： 在这里观看

Firebase功能 ( Firebase Features )

Firebase comes with a ton of things out of the box. You can pick and choose what you want to use and leave what you don't need. You may even come back in the future and use those extra features as your application grows.

Firebase开箱即用。 您可以选择要使用的内容，并保留不需要的内容。 您甚至将来可能会回来，并随着应用程序的增长使用这些额外的功能。

The amount of things that come with Firebase is staggering. It's basically a startup in a box.

Firebase附带的功能数量惊人。 基本上，这是一个盒子里的创业公司。

Firebase教导前端开发人员使用分布式架构 ( Firebase teaches front-end devs to use a distributed architecture )

Firebase enables a distributed architecture.

Firebase启用了分布式架构。

New developers have traditionally learned to build monolithic apps.

传统上，新开发人员学会了构建整体应用程序。

A monolith is a single application server that holds your database and server. Everything lives on a single server that you control, so it's very easy to teach and understand.

整体式服务器是容纳数据库和服务器的单个应用程序服务器。 所有内容都驻留在您控制的一台服务器上，因此非常容易教授和理解。

The first managed service that I used was Amazon S3. It was an endpoint where I could send files. S3 would save the files and give me a link. I'd save the link in my local SQL database and S3 would serve the file to my users.

我使用的第一个托管服务是Amazon S3。 这是我可以发送文件的端点。 S3将保存文件并给我一个链接。 我将链接保存在本地SQL数据库中，S3会将文件提供给用户。

Managed services are used to create distributed systems. Each part of the system is optimized for a small part of the puzzle. Developers compose these systems together.

托管服务用于创建分布式系统。 系统的每个部分都针对拼图的一小部分进行了优化。 开发人员将这些系统组合在一起。

AWS and GCP provide extremely powerful, complicated managed services aimed at large, enterprise users. They're not built for indie devs. And that's where Firebase comes in.

AWS和GCP针对大型企业用户提供了功能强大，复杂的托管服务。 它们不是为独立开发人员打造的。 这就是Firebase的用武之地。

Firebase lets you quickly deploy managed services for small- to medium-sized apps. And you can roll in heavier-duty Google Cloud Platform (GCP) services as your app grows.

Firebase可让您快速为中小型应用程序部署托管服务。 而且，随着您的应用程序的增长，您可以使用重型Google Cloud Platform（GCP）服务。

SQL的替代方法 ( An Alternative to SQL )

Most developers are raised on SQL.

大多数开发人员都对SQL感兴趣。

SQL is great for modeling relational data, but guess what! Most data is not as relational as you may think.

SQL非常适合对关系数据进行建模，但是您猜怎么着！ 大多数数据并不像您想象的那样具有关联性。

SQL is ideal when you don't know how you're going to query your data. You simply store your data in third normal form and SQL lets you query it into almost any structure for your front end.

当您不知道如何查询数据时，SQL是理想的选择。 您只需将数据存储为第三种标准格式 ，SQL便可以将其查询为前端的几乎任何结构。

Firebase and other NoSQL datastores optimize for reads, which are much more common than writes. So instead of writing once and reading in many different ways like with SQL... NoSQL/Firebase asks you to write the data to match your reads.

Firebase和其他NoSQL数据存储针对读取进行了优化，这比写入更为常见。 因此，与其编写一次并以多种不同的方式（例如使用SQL）进行读取，不如... NoSQL / Firebase要求您写入数据以匹配您的读取。

Firebase会粉碎其他数据库（对于许多用例而言） ( Firebase crushes other databases (for many use cases) )

Let's say that I have new user sign up for a multi-player RPG. I want to show that user's email address on their profile, next to any messages that they send to other users. Finally, I'll need a list of all user emails for my admin dashboard.

假设我有新用户注册了多人RPG。 我想在他们发送给其他用户的所有邮件旁边显示该用户的电子邮件地址。 最后，我需要管理控制台的所有用户电子邮件列表。

Firebase asks you to write that email address in three different places, one for each type of read operation. "But Chris!" you ask. What if I need to change the email address??? Isn't that inefficient???

Firebase要求您在三个不同的位置写入该电子邮件地址，每种读操作类型一个。 “但是克里斯！” 你问。 如果我需要更改电子邮件地址怎么办？？？ 那不是效率低下吗？？？

Yep. It's inefficient. You'll have to update that email address in three places, and you'll have to be careful to track everywhere that you saved it.

是的 效率低下。 您必须在三个位置更新该电子邮件地址，并且必须小心跟踪保存的电子邮件地址。

But how often do you actually need to write an email address? What about the reads???

但是，您实际上需要多久写一次电子邮件地址？ 读什么呢？

The reality, and the reason that Firebase works so well, is that most apps read data significantly more than they write it.

现实以及Firebase之所以如此出色的原因是，大多数应用程序读取数据的能力远远超过写入数据的能力 。

So get over your SQL-induced anxiety and duplicate data throughout your Firebase data structure. Your database reads will dramatically outperform SQL reads at scale.

因此，克服了SQL引起的焦虑，并在整个Firebase数据结构中重复了数据。 您的数据库读取将在规模上大大超过SQL读取。

邪恶的孪生数据库 ( The Evil Twin Databases )

Firebase now has two databases,

Firebase现在有两个数据库，

1. the Realtime Database, also known as classic Firebase or the RTDB, and
   实时数据库 （也称为经典Firebase或RTDB），以及
2. Cloud Firestore.
   云Firestore 。

The Realtime Database is ideal for fast, high-volume operations. I use the RTDB for tracking how many users I have online at any one time. I use it for job queues that are consumed with Cloud Functions.

实时数据库是快速，大批量操作的理想选择。 我使用RTDB来一次跟踪我有多少用户在线。 我将其用于Cloud Functions消耗的作业队列。

Firestore is better for longer-lived, more structured data. I use Firestore for 90% of my data storage. You pay by the operation, so it's not ideal for extremely frequent reads and writes... but that's why we have the RTDB :)

Firestore适用于寿命更长，结构更清晰的数据。 我将Firestore用于90％的数据存储。 您通过操作付费，因此对于非常频繁的读写来说并不理想...但这就是我们拥有RTDB的原因:)

I use Firestore for user profiles, chat logs, purchase records... anything that I need to stick around for a while.

我将Firestore用于用户个人资料，聊天记录，购买记录...我需要坚持一会儿的所有内容。

Firebase便宜而且快得多 ( Firebase is cheap and much, much faster )

The Iron Triangle of Project Management states that all projects are compromises between cost, scope and time.

项目管理的铁三角指出，所有项目都是成本 ， 范围和时间之间的折衷。

Firebase is the lowest-cost and fastest development experience of which I'm aware. The free plan will get you very far and when you outgrow that, the $25 plan has good amounts of space for your app.

据我所知，Firebase是成本最低，最快的开发经验。 免费计划将使您走得更远，而当您超出预算时，25美元的计划将为您的应用提供足够的空间。

I bootstrap projects on a regular basis. Most of my projects are solo projects. I'm the developer, designer and marketer. I'm incredibly time-constrained, so I use Firebase to enable me to achieve greater scope while keeping my time costs low.

我会定期引导项目。 我的大部分项目都是个人项目。 我是开发商，设计师和营销商。 我的时间非常有限，因此我使用Firebase使我能够实现更大的范围，同时保持较低的时间成本。

I've built the following projects entirely on my own with Firebase:

我已经完全使用Firebase构建了以下项目：

• calligraphy.org: Online teaching platform integrated with Shopify
  calligraphy.org ：在线教学平台集成了Shopify
• HiiTClock.com: PWA workout timer
  HiiTClock.com：PWA锻炼计时器
• pixels.chrisesplin.com: Chrome extension for UI development
  pixel.chrisesplin.com ：用于UI开发的Chrome扩展
• bunches.chrisesplin.com: Multi-player card game
  bundlees.chrisesplin.com ：多人纸牌游戏

Calligraphy.org powers my wife's business. It took me four months to write it in the mornings before my full-time job. It would have taken twice as long without Firebase.

Calligraphy.org支持我妻子的生意。 在我从事全职工作之前，我花了四个月的时间来编写它。 如果没有Firebase，那将花费两倍的时间。

The other projects took between 75 and 200 hours each. Again, I finished them in my spare time while relying heavily on Firebase.

其他项目每个花费了75到200个小时。 同样，我在业余时间完成了它们，同时严重依赖Firebase。

Firebase has spoiled me. I've used Firebase instead of SQL since 2013. And these aren't just rapid prototypes. They're fully-functional, scalable and used by thousands of customers.

火力基地宠坏了我。 自2013年以来，我一直使用Firebase代替SQL。这些不仅仅是快速的原型。 它们功能齐全，可扩展，并被成千上万的客户使用。

Firebase几乎包含构建中小型应用程序所需的所有内容 ( Firebase includes nearly everything I need to build small- to medium-sized apps )

The pillars of Firebase's web offering are

Firebase网络产品的Struts是

• the Realtime Database (json database),
  实时数据库（json数据库），
• Cloud Firestore (document/collection database),
  Cloud Firestore（文档/集合数据库），
• Cloud Functions for Firebase (serverless functions),
  Firebase的云功能（无服务器功能），
• Firebase Storage (file/blob storage), and
  Firebase存储（文件/ blob存储），以及
• Firebase Hosting (static file hosting).
  Firebase托管（静态文件托管）。

These five pillars can support an enormous range of apps.

这五个Struts可以支持各种应用程序。

Realistically, you'll need to "cheat" on Firebase a bit for larger apps. I use GCP for a few things that don't fit neatly within the Firebase offering. I also use Algolia to power my search.

实际上，对于大型应用程序，您需要在Firebase上“作弊”。 我将GCP用于Firebase产品中无法很好地解决的一些问题。 我还使用Algolia来推动搜索。

The funny thing is that Algolia is the most expensive part of my stack at $35/month. The Firebase databases are optimized for everything except search. This is an important caveat to recognize early. Searching Firestore collections or anything in the Realtime Database is extremely limited, and for strong architectural reasons. I don't expect to ever see Firebase support search.

有趣的是，Algolia是我堆栈中最昂贵的部分，每月35美元。 Firebase数据库针对除搜索之外的所有内容进行了优化。 这是需要尽早发现的重要警告。 出于强大的架构原因，搜索Firestore集合或实时数据库中的任何内容都非常受限制。 我不希望看到Firebase支持搜索。

I primarily use GCP to manage the DNS for my domains. And I sometimes run Cloud Compute instances for small, custom tasks.

我主要使用GCP来管理我的域的DNS。 有时，我会为小型自定义任务运行Cloud Compute实例。

I also use GitLab.com for CI/CD purposes... so I guess I step out on Firebase a couple of times on each project :)

我还使用CI / CD来使用GitLab.com ...所以我想我在每个项目上都在Firebase上走了两次:)

Firebase轻松扩展 ( Firebase scales effortlessly )

Firebase does not allow slow operations. The database does not execute joins. It doesn't search.

Firebase不允许运行缓慢。 数据库不执行联接。 它不会搜索。

I haven't personally built a Firebase app up to massive scale. I've heard that the Realtime Database can run into limits and require manual sharding; however, Firestore is architected much differently, and I wouldn't be surprised if it scales more like Cloud Spanner.

我个人还没有大规模构建Firebase应用程序。 我听说实时数据库可能会遇到限制，需要手动分片。 但是，Firestore在架构上有很大不同，如果像Cloud Spanner那样进行扩展，我也不会感到惊讶。

Firestore has some awesome performance characteristics.

Firestore具有一些出色的性能特征。

From the Firestore marketing page:

从Firestore营销页面 ：

All queries scale with the size of your result set (note: not your data set), so your app is ready to scale from day one.

所有查询都会根据结果集的大小进行扩展（注意：不是您的数据集），因此您的应用程序可以从第一天开始进行扩展。

Firestore also offers strong consistency, meaning that you don't have to worry about the eventual-consistency data models that bedevil most NoSQL implementations.

Firestore还提供了强大的一致性，这意味着您不必担心大多数NoSQL实现都不愿拥有的最终一致性数据模型。

GCP是逃生舱口 ( GCP is the escape hatch )

Firebase services are built on Google Cloud Platform (aka GCP) infrastructure, and some of them are closely integrated.

Firebase服务建立在Google Cloud Platform（aka GCP）基础架构上，其中一些紧密集成。

For instance, Firebase Cloud Storage uses GCP Storage buckets that you can access through the GCP SDKs.

例如，Firebase Cloud Storage使用可以通过GCP SDK访问的GCP存储桶。

GCP is an enterprise-focused suite of services. It's massive.

GCP是一个以企业为中心的服务套件。 很大

Each Firebase project comes with its own GCP account, granting you access to the full power of GCP. So don't worry if Firebase doesn't fulfill your every need. GCP has it covered.

每个Firebase项目都有其自己的GCP帐户，使您可以使用GCP的全部功能。 因此，如果Firebase无法满足您的所有需求，请不要担心。 GCP已涵盖。

For example, If you don't want to pay for Algolia, you can spin up an Elasticsearch cluster on GCP and roll your own search. It'll be just as expensive as Algolia... so I can't recommend it for small projects; however, those capabilities are all there.

例如，如果您不想为Algolia付费，则可以在GCP上启动Elasticsearch集群并进行自己的搜索。 它的价格和阿尔戈利亚一样高，所以我不建议在小型项目中使用。 但是，这些功能全都存在。

Firebase的常见问题 ( Common concerns with Firebase )

Firebase has it's downsides!

Firebase有它的缺点！

• Firebase cannot be hosted locally.
  Firebase无法在本地托管。
• Firebase is tough to mock for local unit tests.
  Firebase很难模拟本地单元测试。
• There's far less tooling available than for SQL databases.
  与SQL数据库相比，可用的工具少得多。
• Firebase can get expensive if you implement it poorly.
  如果实施不当，Firebase可能会变得昂贵。

None of these problems bothers me. It may be Stockholm Syndrome... but I'm at peace with all of these "problems" with Firebase.

这些问题都没有困扰我。 可能是斯德哥尔摩综合症……但我对Firebase遇到的所有这些“问题”都持平和态度。

Engineering is all about tradeoffs. Firebase trades a bunch of control and autonomy for speed and simplicity of development.

工程就是权衡。 Firebase为控制开发速度和简化性而进行了大量控制和自治。

何时不使用Firebase ( When to NOT use Firebase )

DO NOT use Firebase for highly relational data.

不要将Firebase用于高度相关的数据。

DO NOT use Firebase for complex graph data.

请勿将Firebase用于复杂的图形数据。

DO NOT use Firebase for complex server needs.

不要将Firebase用于复杂的服务器需求。

I sometimes recommend hybrid architectures. Store your relational data in GCP's Cloud SQL or Cloud Spanner databases. Store your graph data in JanusGraph on top of Cloud Bigtable.

有时我会推荐混合架构。 将您的关系数据存储在GCP的Cloud SQL或Cloud Spanner数据库中。 将您的图形数据存储在Cloud Bigtable顶部的JanusGraph中。

But these are all advanced use cases! Don't worry about them until you need them.

但是这些都是高级用例！ 在需要它们之前，请不要担心它们。

竞赛 ( The competition )

Firebase's direct competition is dead. Facebook killed off Parse and RethinkDB suffered a similar fate.

Firebase的直接竞争已死。 Facebook杀死了Parse ， RethinkDB也遭受了同样的命运。

The most direct alternative to Firebase at this point is AWS or GCP. They're much more complicated and harder to use... but you could achieve similar architectures with other services.

目前，Firebase的最直接替代方法是AWS或GCP。 它们更加复杂且难以使用...但是您可以使用其他服务来实现类似的体系结构。

Or just use Postgres. Postgres is killer... as long as you have budget to write your own API on top of it.

或者只是使用Postgres。 只要您有预算在其上编写自己的API，Postgres就是杀手...。

That's about it. Use AWS, GCP or Postgres. Your dev velocity will suffer, but at least with Postgres you can run everything locally!

就是这样 使用AWS，GCP或Postgres。 您的开发速度会受到影响，但至少可以使用Postgres在本地运行所有内容！

I've worked in a corporate setting with Postgres running in a local Docker container, and it's slick. I didn't write that API myself. It was expensive to maintain, and I could have duplicated it in Firebase at a much lower cost. But the business I was working with wasn't a fan of managed services. What could I do :)

我曾在公司环境中工作过，而Postgres在本地Docker容器中运行，而且很漂亮。 我不是自己写API的。 维护成本很高，我可以以更低的成本在Firebase中复制它。 但是我与之合作的企业并不喜欢托管服务。 我能做什么 ：）

结论：Firebase是大多数前端应用程序的首选 ( Conclusion: Firebase is preferred for most front-end-focused apps )

Firebase is a slam dunk for small- to medium-sized projects, especially if they're front-end focused.

Firebase是中小型项目的灌篮，特别是如果它们集中在前端。

You may need to re-architect if you hit massive scale... but you always have to re-architect for massive scale. Don't prematurely optimize for scale.

如果规模很大，您可能需要重新架构...但是您始终必须大规模地重新架构。 不要过早优化规模。

Choose Firebase because it gets you to market faster. It helps you validate your ideas and get feedback.

选择Firebase，因为它可以使您更快地推向市场。 它可以帮助您验证想法并获得反馈。

Firebase is a cornerstone of Google's cloud strategy. It's not going anywhere.

Firebase是Google云战略的基石。 它不会去任何地方。

翻译自: https://scotch.io/tutorials/firebase-get-your-apps-off-the-ground-blazing-fast

firebase