Firebase 與 Ruby：移動應用開發中的後端哪個更好？

為您的 iOS 或 Android 應用程序選擇後端堆棧可能很困難。 這就是為什麼在這裡我們比較 Firebase 與 Ruby on Rails 編寫的後端，並調查是否有任何用於移動應用程序開發的後端技術的“神風選擇”。 有什麼理由不使用 Firebase 或 Ruby？ 是否可以將 firebase 與 Ruby on Rails 一起使用？ 讓我們發現。

如果我說營銷是一場爭奪人們注意力的競賽，您是否同意我的觀點？ 更重要的是，營銷太重要了，不能留給營銷部門。 它甚至爬到了與推廣無關的利基市場——軟件開發； 營銷已經成為其中的一部分。 開發人員根據 Github 上一些類似庫的星級為他們的項目選擇解決方案，以及我們能夠預測今年哪些技術將積極增長的帳戶“推文”數量。 這種數字環境使我們面臨成為炒作受害者的風險，我們可能會在這種情況下被誤導 - 只是愛上了由邪惡的營銷人員創造的高度推薦的炒作工具。

最近每個人都在談論的工具之一是 Firebase 及其 API，這是一個由 Firebase, Inc. 於 2011 年開發的移動和 Web 應用程序開發平台，然後在 2014 年被谷歌收購，正如維基百科所說。 在 2014 年 Firebase 被谷歌收購之前，沒有證據表明該產品的快速增長，並且一些人聲稱 Firebase 存在劣勢。 雖然從那時起有些事情發生了變化。 Firebase 已在製作應用程序的過程中實施，例如：

• 沙贊
• 阿里巴巴訂單和交付應用程序
• Todoist 應用程序管理器

像 Shazam 這樣的巨頭顯然不會進行肆意的預算支出，因此，對他們來說，Firebase 是一個相當合理的選擇。 我們試圖查看 Firebase 實施的利弊，試圖找出它最適合哪個項目。

但是在我們深入了解 Firebase 的優勢之前，有兩點需要說明 - 消除可能發生的所有可能的誤解：

1. Firebase 最初並不打算作為後端選項，該平台的核心是一個數據庫。 沒有集成服務器部分的奇蹟般開發的應用程序並不像。
2. 雖然它不是關係數據庫。 Firebase 是一個NoSQL基礎，附帶所有優點和缺點 + 特定的 Firebase 開發環境和架構。

什麼是 NoSQL 數據庫？

根據 Basho 的說法，NoSQL（意思是“Not SQL”或“Not Only SQL”）是一種數據庫方法，代表了對傳統關係數據庫管理系統 (RDBMS) 的轉變。 要定義 NoSQL，從描述 SQL 開始會很有幫助，SQL 是 RDBMS 使用的一種查詢語言。 關係數據庫依靠表、列、行或模式來組織和檢索數據。 相比之下，NoSQL 數據庫不依賴於這些結構，而是使用更靈活的數據模型。 NoSQL 對於存儲大量非結構化數據特別有用，其獲取速度比結構化數據更快。

相反，結構化查詢語言 (SQL) 是數據庫架構師用來設計關係數據庫的一種編程語言。 在 MySQL、Sybase、Oracle 或 IBM DM2 等 SQL 數據庫中，SQL 通過更新、刪除或創建新記錄來執行查詢、檢索數據和編輯數據。 SQL 是一種輕量級的聲明性語言，它為關係數據庫做了很多繁重的工作，就像服務器端腳本的數據庫版本一樣。
[來源：Upwork]

現在我們已經確定我們在同一頁面上，讓我們提取使用 Firebase 的一些優勢。

1. Firebase 可能更省時。

一旦您開始使用 Firebase 作為後端構建實時應用程序，就不會包含服務器部分開發——因為 NoSQL 不需要它。 因此，從短期來看，這個平台可能需要更少的時間來開發。 一旦您想創建一個簡單的應用程序，並為其配備一個小型的無大數據後端，那麼 Firebase 就可以快速實施到項目中。 當您有設定的截止日期或即將發生的事件時，Firebase 可能是一個不錯的臨時解決方案。

2. Firebase 是一個實時解決方案。

如果您需要即時推送通知和更新，那麼您需要所謂的實時應用程序。 就 Firebase 而言，有許多代碼實驗室為它編寫 - 其中一些向您展示瞭如何為不同平台構建聊天應用程序：

• IOS
• 安卓
• 網絡

這給了我們一個遵從的理由——Firebase 的所有優點和缺點，它都能滿足實時通信應用程序的需求。

3. Firebase 開發是一個非常安全的解決方案。

只要 Firebase 建立在 Google 的基礎架構上，就有充分的理由表明它是一個受到良好保護的解決方案。 雖然您可以通過定義 NoSQL 數據庫的規則來加倍安全性，因為默認情況下您無法控制存儲的數據 - 它託管在 Google 的服務器上。

每朵玫瑰都有刺。

因此，如果您打算讓成千上萬的人使用您的產品，那麼 Firebase 可能是一個毫無價值的解決方案。

一旦您選擇 Firebase 作為主要後端堆棧，您需要考慮以下幾點。 不是使用 firebase 的缺點，只是你需要知道的事情。 使用 Firebase，您可以自由選擇定價方案 - 但適合實時應用程序的方案是“現收現付”方案。 使用此計劃，您只需為消耗的資源付費，因此您的應用獲得的用戶越多 - 後端維護成本就越高。

許多人認為這是一個加分項 - 因為您產品的許多用戶都很棒，不是嗎？ 但是，一開始很難將所有產品都貨幣化 - 您首先需要讓人們喜歡您的產品。 如果使用 Firebase，您將可以為所有免費用戶花錢。 因此，如果您打算讓成千上萬的人使用您的產品，那麼 Firebase 可能是一個毫無價值的解決方案。

有傳言說 Firebase 也有隱藏成本，在用戶或使用量快速增長之後，您可能會在沒有警告的情況下收取費用； 因此，如果您不擔心被默默收費 - 那就去做吧。

這就是為什麼您的應用程序的另一個不錯的後端選項是 Ruby 後端 + 用於數據存儲的特定服務器（這是我們在處理客戶項目時經常使用的方法）。 此外，Ruby on Rails 後端和 Firebase 的優點或多或少相同。 在 Ruby 的情況下，它們如下所示：

1. Ruby 是一種簡單的語言。

即使與 PHP 語言及其源代碼相比，它也有一個簡短的框架列表可以實現，但是有很多 gem - 一個完整的 Ruby 多用途庫系統。 同樣簡單的是語言架構模式 - MVC，具有明確的實體依賴關係。

閱讀更多關於架構模式的類型和功能

2. Ruby 社區經受住了時間的考驗。

與新成立的 Firebase 開發者協會不同，Ruby 的社區非常龐大，它擁有大量的開源 gem，可以讓編碼人員快速打開和開發複雜的應用程序。 更重要的是，由於某些 Ruby 的“名氣”，許多著名的服務（如 Stripe）都為 Ruby 提供了現成的庫。

3. 您可以在 Ruby 上測試您的代碼。

Ruby 擁有先進的開發基礎設施，允許在整個項目中最大化和編寫單元測試 - 以減少新功能和現有功能中的錯誤。 這也將減少未來在開發過程中更改的成本。

4. 您不依賴於特定類型的數據庫。

或者，更準確地說，是特定類型的數據庫。 Ruby 允許您使用任何關係型或東方型數據庫，以及 NoSQL 和其他不同的技術——包括 Elasticsearch、Reddis 和其他不太流行的技術。

5. Ruby 的語法是小菜一碟。

Ruby 中沒有數據類型——並且分別不需要查看數據類型的結構是否適當。 此外，還存在可組合錯誤系統（也稱為日誌記錄系統）； 這使得搜索錯誤更容易，然後可以更快地修復發生的錯誤。

所以，Firebase 與 RoR - 選擇哪一個，何時選擇？

在 Firebase 與 Rails 比較之後，外交的答案是 - 這主要取決於您的目標。

如果您需要以下其中一項，Firebase 作為移動應用開發的後端非常適合您：

• 具有簡單功能的小型實時應用程序
• 一個簡單的應用程序，您需要在其中存儲負載和負載
• 一款經過概念驗證的應用程序，稍後將進行全面翻新

雖然如果您希望創建一個複雜的移動系統，具有令人困惑的算法和功能，Ruby on Rails 移動應用程序後端也是一個不錯的選擇。 此外，如果應用程序沒有清晰的結構，在非關係型數據庫中，Firebase 雲後端無疑是，您無法從中正確選擇數據。 在 Firebase 上創建的業務邏輯通常放在 base 中； 因此，當應用程序邏輯有點混亂時，可能會出現大雜燴。 並且不要忘記，每次您獲得新用戶時都會向您收費，即使您沒有通知您 - 您的錢可能會在您醒來的某個早晨簡單地轉移。

希望閱讀本文能幫助您了解如何在移動應用程序開發中使用 Firebase - 如果您覺得它符合您的需求。

另請閱讀：React Native vs Native App Development - 選擇哪一個？

由奧列格·察連科和埃琳娜·貝薩拉波娃撰寫