Home >> Blog >> 什麼是firebase？完整解說
什麼是firebase？完整解說
這些天似乎有一個適用於所有事物的應用程序。好吧，幾乎所有東西。我還沒有找到可以幫助我去除受影響的耳垢的應用程序。它有時會發生在我身上，而且非常令人討厭。但是有人可以建造它！我會為你的 Kickstarter 捐款。
如果您是通過移動應用程序解決人類迫切需求的進取型人，您會想了解Firebase。Firebase 是 Google 的移動應用程序開發平台，可幫助您構建、改進和發展您的應用程序。
為了影響，這裡再次用更大的字母表示：
Firebase 是 Google 的移動應用程序開發平台，可幫助您構建、改進和發展您的應用程序。
現在您知道 Firebase 是什麼了。理論上，這篇文章是可以做到的！
超越行銷文案
當有人問我“什麼是 Firebase？”時，我的心情很複雜。（這種情況經常發生，因為我正在研究它）。一方面，很高興知道有興趣！另一方面，它有這麼多，我什至從哪裡開始？上面的定義是準確的，但根本不是很具體。
我喜歡復古遊戲，所以我再嘗試用一張圖來解釋一下 Firebase：
這很有意義——如果你是我的話！但我知道你們中的許多人不是我，所以如果沒有幫助你們，我很抱歉。
拋開所有的玩笑（僅適用於本段的其餘部分），Firebase 是一個用於“構建、改進和發展您的應用程序”的工具集，它為您提供的工具涵蓋了開發人員通常必須自己構建但實際上並不想構建的大部分服務，因為他們寧願專注於應用體驗本身。這包括分析、身份驗證、資料庫、配置、文件存儲、推送消息等內容，不勝枚舉。這些服務託管在雲中，開發人員幾乎不費吹灰之力就可以擴展。
當我說“託管在雲中”時，我的意思是產品具有完全由Google維護和運營的後端組件。Firebase 提供的客戶端 SDK直接與這些後端服務交互，無需在您的應用和服務之間建立任何中間件。因此，如果您使用 Firebase 資料庫選項之一，您通常會編寫程式碼來查詢客戶端應用程序中的資料庫。
這與傳統的應用程序開發不同，後者通常涉及編寫前端和後端軟體。前端程式碼只是調用後端公開的 API 端點，而後端程式碼實際完成工作。然而，對於 Firebase 產品，傳統的後端被繞過了，將工作交給了客戶端。Firebase 控制台提供對這些產品的管理訪問權限。
如果您認為自己是“後端工程師”，您可能會聽到這個並認為您的工作正在被淘汰！“天啊，沒有更多的後端了——現在我要學習前端開發了！” 這不是真的，因為出於各種原因，有些東西應該放在後端。Firebase 認識到了這一點，並提供了一種進行後端開發的方法，這對您正在開發的應用程序是有意義的。所以，別擔心，你的工作是安全的，我稍後會詳細討論。
由於 Firebase 產品的工作方式，有些人可能將 Firebase 稱為“平台即服務”或“後端即服務”。我從來沒有真正感到過將 Firebase 完全融入其中一個盒子中。Firebase 就是 Firebase。（這句話顯然無助於解釋Firebase 是什麼，這應該是本文的目的！）
無論如何，在撰寫本文時，我統計了 Firebase 套件中的 17 個單獨產品。這是另一張有用的圖片：
都說一張圖抵得上一千個字。我數了數圖片中的 37 個，包括兩個不是真正單詞的東西。事實證明，你今天很幸運，因為我將嘗試用完這篇文章中的其他 963 個隱喻詞來幫助更好地解釋這張圖片。但我不會數他們。
如果你想知道 Firebase不是什麼，那麼你必須一直閱讀到這篇文章的結尾。不要跳過！你會錯過所有的笑話！
Firebase 適用於哪些類型的應用程序？
Firebase 產品可以幫助的應用類型確實沒有限制。它可以使用的平台只有限制。iOS和Android是 Firebase SDK 的主要目標，並且對web、Flutter、Unity和C++的支持越來越多。您還應該知道有一個適用於多種語言的Admin SDK ，可與您可能需要的任何後端組件一起使用。
在這些 SDK 之上，還有一個名為 FirebaseUI（Android、iOS、web）的庫，它提供了許多有用的實用程序，使使用 Firebase 進行開發更加容易。還有一些項目，如AngularFire，它們包裝了 Web SDK 以與 Angular 一起使用。這些是開源的。Firebase 喜歡開源。
下面是幾個使用 Firebase 的開發人員示例。
Greta 使用 Unity 構建手機遊戲：
肖恩正在構建一個社交網絡應用程序：
您可以從他們臉上的表情看出他們正在使用Firebase 構建應用程序。
Greta 並不認為自己是“應用程序開發人員”。遊戲不是應用程序！還是他們？我不知道。但遊戲和傳統應用程序有很多類似的需求，Firebase 可以滿足這些需求。為了好玩，我只是想像遊戲是具有高度自定義 UI 的應用程序，恰好有一個非常強大的遊戲化策略。無論如何，Greta 和 Shawn 面臨著類似的挑戰，儘管他們正在構建非常不同的東西。
為了了解 Firebase 產品在應用程序中的實際作用，我將瀏覽上圖中的各個產品。你在上面看到了三個主要的產品組：“構建”、“改進”和“成長”（但這些分類並不嚴格）。我將首先討論“構建”組，並給出 Greta 和 Shawn 使用每種產品的一些具體案例。
構建你的應用程序——創造“膽量”
“構建”產品組是：
身份驗證- 用戶登錄和身份
實時資料庫- 實時、雲託管、NoSQL 資料庫
Cloud Firestore - 實時、雲託管、NoSQL 資料庫
雲存儲- 可大規模擴展的文件存儲
雲功能- “無伺服器”、事件驅動的後端
Firebase 託管- 全球網絡託管
ML Kit — 用於常見 ML 任務的 SDK
Firebase 身份驗證負責讓您的用戶登錄和識別。該產品對於正確配置其他一些產品至關重要，特別是如果您需要限制對每個用戶資料的訪問（幾乎每個應用程序都希望這樣做）。
irebase 身份驗證的特別之處在於它可以輕鬆執行安全登錄，而您自己很難正確實施。而且它是“聯邦”的，也就是說行星聯合聯合會鼓勵使用它。以下是聯邦隊長 Picard 對實施您自己的身份驗證系統的看法：
其他人可能會說“聯合身份”意味著您可以將來自不同身份提供商（Facebook、Twitter、Google、GitHub）的用戶帳戶連結到 Firebase 身份驗證上的單個帳戶。但我更喜歡我的定義。
無論如何，我強烈建議您先學習身份驗證並將其集成到您的應用程序中，這有望促使您考慮使用其他“構建”組產品可能存儲的每用戶資料的安全性。
Firebase 實時資料庫和Cloud Firestore提供資料庫服務。我將它們都列為“實時、雲託管、NoSQL 資料庫”。他們有各自的長處和短處，您可能需要做一些研究，以確定哪一個更適合您的需求。提示：從 Cloud Firestore 開始，因為它可能會滿足您的更多需求（而且它還具有大規模的可擴展性）。如果適合您的應用，您可以使用其中一個或同時使用兩者。
值得注意的是，Firestore 在技術上是Google Cloud 產品，而不是 Firebase 產品。為什麼它與 Firebase 一起列出？Firebase 添加 SDK 以在您的移動應用程序中使用，以使直接資料訪問成為可能，從而消除了對那個討厭的中間件組件的需求。此處列出的其他產品與 Google Cloud 有類似的關係，我也會注意到這一點。
這些資料庫的真正特別之處在於，當資料庫中的資料發生變化時，它們會為您提供“實時”資料更新。您使用客戶端 SDK 在您的應用程序想要使用的資料的位置設置一個“監聽器”，並且每次觀察到更改時都會使用該資料重複調用該監聽器。這使您可以保持應用程序的顯示新鮮，而無需輪詢感興趣的資料。
有了這樣的實時資料，我們的朋友 Greta 在她的遊戲中使用實時資料來維護遊戲內活動的實時排行榜，供所有人查看。肖恩使用它們在他的社交網絡上的朋友之間提供消息。因為我們只是沒有足夠的聊天應用程序！
有趣的事實：Realtime Database 在 2014 年加入 Google 之前是最初的“Firebase”。直到今天，人們仍然通俗地（但不正確地）將 Realtime Database 稱為“Firebase”。但你不應該這樣做，因為這是錯誤的。
Cloud Storage提供可大規模擴展的文件存儲。從技術上講，它也是Google Cloud 產品，而不是 Firebase 產品。借助 Cloud Storage for Firebase，您可以獲得可在應用中使用的客戶端 SDK，使您能夠直接在 Cloud Storage“存儲桶”中上傳和下載文件。
Greta 的遊戲使用 Cloud Storage 讓人們上傳自定義頭像以在遊戲中顯示，Shawn 的社交網絡讓人們相互分享他們的照片。他們都不擔心空間不足，因為 Cloud Storage 可以擴展到EB級資料。您曾經存儲過 EB 的資料嗎？你甚至有一個關於有多少資料的心智模型嗎？我不！但是我計算了一些數字，讓我們說這個星球上的每個人都可以存儲 1000 張高質量的照片。如果您發布實現這一壯舉的應用程序，請聯繫我！
使用安全規則（適用於Realtime Database、Firestore和Cloud Storage ），身份驗證與這三種產品配合得非常好，您可以使用這些安全規則在源頭設置對資料的訪問控制。這樣可以確保客戶端只能以您允許的方式訪問該資料，從而避免上述 lolrus 的悲慘情況。使用身份驗證登錄到應用程序的用戶將自動提供一個標識令牌，您可以在規則中使用它來保護誰可以讀取和寫入哪些資料項。因此，如果您存儲有關用戶的個人資料，絕對使用帶有安全規則的 Firebase 身份驗證來適當地限制訪問。如果您的規則顯得過於寬鬆，您甚至可能會收到 Firebase 的溫和提醒。
Cloud Functions是另一可與其他 Firebase 和 Cloud 產品完美配合的Google Cloud產品。使用適用於 Cloud Functions 的 Firebase SDK，您可以編寫和部署程式碼，在 Google“無伺服器”基礎架構上運行，自動響應來自其他 Firebase 產品的事件。沒錯，它是無伺服器的！
當人們說“無伺服器”時，他們並不表示缺少伺服器。使用無伺服器後端架構，仍然有伺服器在運行，您不必對它們了解太多。您不會配置、維護、擴展或執行傳統（或“服務式”，我的話）架構中所需的任何 devops。您只需編寫和部署程式碼，剩下的交給 Google 來完成。
Cloud Functions for Firebase 是整個 Firebase 套件中的一款產品，它實際上讓您編寫後端程式碼。在我看來，某些類型的程式碼應該在受控的後端環境中運行。你應該給那些後端開發人員一份工作，因為我之前做出的承諾。
您可以使用 Cloud Functions 執行的操作列表非常龐大 —看看所有這些示例！但我將其歸結為一個主要概念：Firebase 產品（資料庫、存儲、身份驗證等）在產品中的資料發生更改時發出事件，並且您部署到 Cloud Functions 的程式碼會響應這些事件而被觸發。
當有人刪除他們的帳戶時，Shawn 使用 Cloud Functions 從他的資料庫和存儲中自動刪除資料（因為在許多情況下必須保護用戶隱私，並且為未使用的資料付費是很糟糕的）。Greta 使用 Cloud Functions 在安全的後端執行遊戲邏輯和評分，因為她知道黑客可能會試圖通過對她的遊戲程式碼進行逆向工程來作弊。
Firebase 託管是一個安全的全球網絡託管 CDN（內容交付網絡）。它非常擅長使用靠近用戶的伺服器快速交付靜態內容（HTML、CSS、JS、圖像）。無論您是否使用自定義域，您都可以快速設置它，並提供免費的 SSL 證書。
Firebase 託管與 Firebase 的其餘部分有一個重要的集成點，那就是通過 Cloud Functions。Firebase 託管允許您在編寫 HTTP 類型函數時代理與 Cloud Functions 之間的請求和響應。而且，更好的是，如果您正確配置它們，它會緩存來自您的函數的響應。構建“RESTful”API 的好方法！
ML Kit for Firebase讓您可以利用 Google 的豐富機器學習專業知識，而無需了解任何有關 ML 的知識。這對我來說很棒，因為我對機器學習一無所知！但我從 ML Kit 中獲得的是識別我的設備相機捕捉到的東西的能力，例如文本、面部和地標。它可以在我的計算能力非常有限的移動設備上運行。對於那些對 ML 有更深入了解的人（同樣，不是我），您可以上傳 TensorFlow 模型以用於更複雜的用例。Firebase 的機器學習產品路線圖將完全“聯合”：
Shawn 使用 ML Kit 在他的社交網絡用戶上傳的照片和視頻中定位人臉，然後對它們進行一些圖像處理。Greta 還沒有使用 ML Kit，因為 SDK 還沒有 Unity 實現。當！但如果有的話，她可能會用它來讓人們掃描 QR“優惠券”程式碼以獲得免費的促銷遊戲內物品。
這就是“構建”組的內容。裡面有很多有用的工具！但是關於 Firebase 仍有很多需要討論的地方。
發展你的應用——吸引和留住用戶
“成長”產品組是：
分析——了解你的用戶，以及他們如何使用你的應用程序
預測——將機器學習應用於分析以預測用戶行為
雲消息——向用戶發送消息和通知/p>
遠程配置——在不部署新版本的情況下定制你的應用程序；監控變化
A/B 測試——運行行銷和可用性實驗，看看什麼最有效
動態連結——支持原生應用轉化、用戶共享和行銷活動
應用索引——通過Google搜索集成重新吸引用戶
應用內消息——吸引你的有針對性消息的活躍用戶
Google Analytics for Firebase是“增長”產品的核心。如果您需要更好地了解您的用戶，以及他們如何使用您的應用，Google Analytics（分析）可以向您展示。當您第一次發布應用程序時，您可能會知道您的用戶群將是誰、他們住在哪里以及他們可能如何使用您的應用程序。這些想法在實踐中可能完全錯誤！唯一確定的方法是收集資料，而這正是 Analytics 可以提供幫助的地方
Google Analytics for Firebase的功能遠不止這裡可以總結的，但有一件重要的事情需要了解，那就是“受眾”的概念。受眾是在您的應用中執行了一些預定義操作、共享一些用戶屬性或具有共同設備特徵的一組用戶。您定義某人成為受眾成員的要求，Analytics 將通過分析您的應用隨時間生成的事件流來確定哪些用戶屬於該受眾。這種受眾細分的概念非常強大，因為您可以使用“增長”類別中的其他 Firebase 產品來定位該受眾。繼續閱讀時，請牢記觀眾的這一概念！
Greta 的遊戲定義了“已完成第 10 關並進行遊戲內購買的玩家”（核心玩家）的受眾群體。Shawn 的社交網絡應用程序將受眾群體定義為“年齡在 18 到 24 歲之間的人，他們在網絡上至少有 50 個朋友”（社交年輕人）。一旦在 Firebase 控制台中定義了這些受眾，並且更新了應用以發送正確的事件，這些受眾就會收集成員。然後，Greta 和 Shawn 可以針對受眾成員提供這些群體感興趣的信息和提議。
Firebase 預測建立在 Analytics 收集的資料之上，以預測（這並不奇怪）您的應用中的哪些用戶可能會流失（不打開您的應用），以及哪些用戶會花費（錢，在您的應用上）。這兩種新的用戶類別有點像 Analytics 受眾，不同之處在於您不需要做任何事情來定義用戶如何最終進入這些組之一。這就是機器學習的魔力！這就像哈利波特中分院帽的魔力，除了沒有人擔心被分到赫奇帕奇。
分析和預測都很有趣，但它們並沒有真正為您的應用做任何事情。但是，當您將它們與其他 Firebase “成長”產品結合使用時，您可以獲得真正神奇的結果！讓我們看看它是如何工作的。
Firebase Cloud Messaging可讓您發送推送消息以指示您的應用或應用用戶感興趣的內容。有兩種發送消息的方法。首先，您可以在後端編寫程式碼，以便在您的應用程序可能想要響應的更新內容（例如，聊天室通知）時對您的應用程序執行 ping操作。其次，您可以在 Firebase 控制台中編寫一條消息，以向您的用戶發送感興趣的信息。這是我今天更感興趣的第二種情況——直接用戶通知。
由於它與 Analytics 和 Predictions 集成，因此您可以對用戶消息執行的一件事是向特定 Analytics 受眾或預測組的成員發送消息。這很有價值，因為您可以針對用戶更可能感興趣並點擊的信息來定位他們，從而讓他們與您的應用保持互動。針對具有相關內容的特定群體比僅僅向所有人發送消息要好。原因很清楚。為了說明這一點，下面這張圖片顯示某人收到了太多與他們的興趣無關的推送消息：
Greta 可能會通知她的核心玩家觀眾有新的遊戲物品待售。肖恩可能會提醒他的社交年輕人評價和討論他們最喜歡的夜總會。在這兩種情況下，在 Analytics 的幫助下，人們收到的消息更有可能採取行動，而收到垃圾郵件的人更少。
Firebase In App Messaging可幫助您向用戶顯示有針對性的可自定義消息，以與您應用的關鍵功能互動。您可能想知道“嗯，這與 FCM 有何不同？” （我很高興你問了！這意味著你還在關注！）這裡的主要區別是來自 FCM 的消息來自你控制的伺服器（包括 Firebase 控制台），而來自 FIAM 的消息來自應用程序本身（但在控制台中配置）。當您的用戶實際使用該應用程序時，保證會顯示該消息。但 FCM 和 FIAM 的相似之處在於它們都與分析和預測深度集成。
FCM 發送的消息完全有可能由於其時間或相關性而對用戶不感興趣，或者甚至被意外忽略。你有沒有註意到上面那個看起來很生氣的女人對推送消息的容忍度很低？！使用 FIAM，根據您定義的標準，由分析事件和預測組衡量的用戶行為確定的標準，在消息變得相關的那一刻傳遞消息。
例如，Greta 的遊戲允許玩家在玩遊戲時賺取虛擬貨幣，並使用 FIAM 提醒剛剛賺取第一筆虛擬美元的人可以在遊戲商店中消費。肖恩的社交網絡向用戶指出，如果他們已經使用該應用一段時間但尚未發現，他們可以選擇分享內容。
Firebase 遠程配置可讓您動態更改應用的行為和外觀，而無需發布應用更新。遠程配置的總體思路是您在 Firebase 控制台中定義一堆配置參數。然後，您的應用程序使用 SDK 定期獲取這些值並根據需要使用它們。您可以將遠程配置想像成一組巨大的雲託管鍵/值對。這聽起來像是一個簡單的資料庫，但您可以用它做的事情遠比您最初想像的要多。
Remote Config 真正的亮點在於它能夠為每個參數定義條件。一種類型的條件允許您將特定值定位到特定的 Analytics 受眾。另一個可讓您針對“流失”或“支出”的預測組。這有助於您在應用程序中實現許多有用的功能，包括為高價值的受眾成員提供優質體驗，或為不常使用的用戶提供留下的動力。
Shawn 使用遠程配置來動態地向特定用戶推廣哪些社交網絡功能。Greta 的遊戲使用它來微調某些關卡和遊戲機制的難度，而無需構建和發布遊戲的新版本。
Firebase A/B 測試進一步加強了 Analytics、遠程配置和 FCM 之間的緊密集成。我想您會不斷地對您的應用程序進行更改，這很好。但是，除非您自己進行研究，否則您可能無法提前確定它是否會有所幫助或傷害。如果您沒有這些資源，您可以進行自己的研究，並用資料備份它們。如果您知道如何衡量成功，您可以使用 Firebase A/B 測試來設置實驗並在做出決定之前對少數用戶進行實驗。這是明智的，因為對應用程序的更改做出不知情的決定可能會導致您的用戶發生這種情況：
Firebase 動態連結建立在現有的“深層連結”概念之上，可將您的應用程序啟動到特定屏幕或定制體驗。如果用戶已經安裝了您的應用程序，深層連結非常有用，但如果他們必須先安裝它，它們就根本無法正常工作。動態連結通過在應用程序安裝過程中倖存下來對此進行了改進。當用戶單擊動態連結且應用尚未安裝時，他們將被定向到相應的應用市場進行安裝。然後，當用戶第一次啟動應用程序時，連結的上下文將被保留，應用程序可以以您最初想要的體驗開始。哦，它們也可以跨平台工作，因此您不需要為每個 Android、iOS 和 Web 應用程序設置不同的連結。
Greta 使用動態連結開展行銷活動，新用戶在第一次點擊連結安裝遊戲時可以獲得免費的遊戲內物品。肖恩使用它們使用戶能夠輕鬆地在他的社交網絡上分享帖子，無論連結在哪里或如何分享。
改進您的應用程序 - 穩定性和性能
“改進”產品組如下：
測試實驗室— 在雲託管設備上進行可擴展的自動化應用測試
Crashlytics — 獲得對應用崩潰的清晰、可行的洞察
性能監控— 深入了解應用的性能問題
Firebase 測試實驗室讓您可以訪問各種 iOS 和 Android 設備，以及虛擬 Android 設備，以測試您的應用。如果您為移動設備構建應用程序，您的辦公桌上可能至少有一台設備用於開發和測試。但這一台設備當然不能代表您的用戶實際使用的設備。移動設備有各種尺寸，來自許多不同的製造商，運行著許多不同版本的操作系統。嘗試維護您自己選擇的設備，然後對所有設備進行實際測試是非常昂貴和耗時的。
測試實驗室通過託管大量實際的物理設備來解決這個問題，這些設備將安裝您的應用程序並針對它運行您的測試套件（Android：Espresso，iOS：XCTest）。它還可以執行不需要額外編碼的全自動測試，對於我們中間真正的懶惰者（就像我們所有人一樣，amirite？）。
Firebase Crashlytics是世界上最好的崩潰報告工具。說真的，這是最好的。我不知道為什麼我什至費心輸入關於它的東西。它一直存在。就用它吧。它甚至與 Analytics 集成，因此您可以衡量崩潰如何影響用戶使用您的應用程序的方式（可能通過卸載它）。應用程序崩潰甚至都不好笑，所以我不會用有趣的圖片來說明每個人都理解的概念。
Firebase 性能監控通過測量應用的 HTTP 請求、啟動時間和使用其 API 的其他程式碼，讓您從用戶的角度深入了解應用的性能問題。這個 Firebase 產品的神奇之處在於，它可以開始測量 HTTP 請求和啟動時間，而您無需編寫超過幾行程式碼，結果在 Firebase 控制台中可見。添加更多行來計時您的應用程序可能正在執行的任何其他操作。
我將強調從用戶的角度獲取指標的重要性。您可能使用快速 wifi 網絡上的快速設備開發您的應用程序。幾乎可以肯定，這種設置與您的用戶在世界各地面臨的條件不同，在帶有低端設備的脆弱移動網絡上。如果您想了解用戶的實際痛苦使用您的應用程序時，請嘗試用一把生鏽的鉗子拉出您的鼻毛。然後，當您最終意識到這是一項毫無意義的練習時，將性能監控集成到您的應用中，並在 Firebase 控制台中研究其結果。您將能夠準確地看到您的應用程序在世界不同地區、不同網絡、不同設備和不同版本的操作系統上可能存在的問題。您將看到哪些 HTTP 端點在您的應用程序中造成了最大的延遲，從而為您提供了一個專注於優化的目標。
不是很明顯的是“改進”類別中的三個產品如何很好地協同工作，即使它們沒有像其他 Firebase 類別中那樣直接集成。您可以做的是在測試實驗室中運行您的應用程序的特殊版本，完成後，您將能夠在 Crashlytics 中看到更詳細的崩潰信息（當然，如果它崩潰了）並在性能監控中看到更好的性能測量。我還知道有人能夠使用 Crashlytics 崩潰報告在性能監控中找到性能問題。你也可以這麼聰明！
哇，有很多文字和圖片
你做到了最後！你猜怎麼著？您剛剛發現Firebase 中有很多東西。那麼你能從這一切中得到什麼？我將把它歸結為幾點，以便您可以重新構建您的應用程序：
- Firebase 是Google的移動應用開發平台。（是的，又是這樣。）
- 您將使用 Firebase 產品節省大量時間和金錢，而不是嘗試自己構建它們。
- 您可以使用所有這些，也可以不使用，或者只使用您想要的部分。
- 所有這些位都旨在很好地協同工作，在一個控制台中進行管理。
- 你會使用 Firebase 來構建那個消除耳垢的應用程序嗎？
附錄：Firebase 不是什麼
以上就是關於 Firebase是什麼的所有重要信息，但我注意到我們還需要一個關於 Firebase不是的所有內容的參考。作為記錄：
- Firebase 是一個平台，而不是（只是）一個資料庫（不再是）。我們已經介紹了這一點。
- 它是“Firebase”，而不是“FireBase”。如果你這樣寫，你會被打在喉嚨裡。
- 同樣，它是“Firestore”，而不是“FireStore”，但一拳打到了腎臟。
- 它永遠不會縮寫為 FB。這樣做，你會被大喊大叫直到你的耳朵流血。
- 如果 Firebase 是一種元素，它會與符號 F 的氟作鬥爭。
- 儘管有語法檢查器的建議，但它是“實時的”，而不是“實時的”
- 它是“Firebase 的雲功能”，而不是“Firebase 功能”。繼續，搜索文檔並證明我錯了。我賭你。
- 它是“Cloud Firestore”，而不是“Firebase Firestore”。說真的，誰需要這麼多火？
- Cloud Firestore 不是 Cloud Filestore 不是 Cloud Datastore 不是 Cloud Memorystore 不是 Cloud Storage。知道了？