二八科技-二八科技新聞資訊

原標題：移動應用后端應該使用AWS還是Firebase？

作者|DhananjayTrivedi

翻譯|天道酬勤，編輯|Carol

出品|CSDN云計算（ID：CSDNcloud）

我們將按以下順序比較這兩種服務：

1. 它們有什么共同點？

2. 如何將它們與你的前端集成？

3. 它們的優勢。

4. 它們的價格。

5. 創建和維護所需的成本。

6. 最后的想法。

在我們開始之前，作者想先聲明一下，本文并非要從兩者中分出一個勝負，所以無論你是哪一方的忠實支持者，都建議你僅客觀看待本篇文章。

因為今天我們所討論的核心問題是：“哪個是適合你需求的解決方案？”

作者已經開發原生Android應用程序已有一段時間了，并且最近開始在Flutter中開發移動應用程序，并且同時將Firebase和AWS用作后端服務。

但是作者最近不得不為移動應用程序尋找解決方案，實際上作者花了很多時間來決定后端的正確服務。

因此，作者在這里與大家分享他的觀點和理解，來幫助你選擇合適的服務而不會浪費很多時間。

這些服務有什么共同點？

核心功能如下：

• 驗證碼

• 推送通知

• 存儲

• 托管

• 分析工具

所有這些都提供了，因此你可以使用這些平臺中的任何一個輕松地部署無服務器解決方案。

你如何將后端與應用程序集成？

集成這些服務的最流行方法是使用它們的SDK，但這是否符合你的需求？

• Firebase

Firebase提供了適用于Android、iOS和Web的SDK，因此，你作為前端開發者，實際上可以輕松構建數據驅動的應用程序，而不必依賴后端技能。

Firebase還具有一個RESTAPI，你可以在想要構建自己的自定義API（根據自己的需求）時使用。

• AWS

AWS為移動開發者提供了一個非常不錯的解決方案，稱為AppSync，你可以將其集成到Android、iOS和ReactNative中。

AWSAppSync中還沒有對Flutter的官方支持，你可以在此網站上閱讀：

https://github.com/aws-amplify/amplify-js/issues/1852

如果要在前端使用Flutter，則必須創建自己的API。

建議

• 查看解決方案的復雜性和業務需求，并牢記可伸縮性，然后決定是否需要創建API。
• 如果要使用API，那么對SDK的依賴就會消失。此外，擁有API對于更大的項目更有意義。
• 如果你的解決方案很簡單，并且你不想花太多精力使用API，那么請選擇提供SDK的服務或前端框架，以便將后端直接集成到前端中。

看看它們的優勢

Firebase和AWS都有其優勢，讓我們看看哪一個可以更好地為你服務？

• AWS

1.設置不同的環境

在AWS中，用于開發、測試和生產的不同環境更加簡潔。

你也可以在Firebase中執行此操作，但是你將必須設置不同的項目，這需要花費更多時間。

2.持續部署

如果你使用過Netlify等服務，則AWS提供了另一個簡潔的解決方案來進行連續部署。同樣，你也可以使用谷歌云進行CD制作，但是需要更多的配置。

3.GraphQL

適用于移動應用程序的AWSAmplifySDK與GraphQL和Apollo緊密集成。

4.數據庫的選擇

你可以完全控制要在后端使用的數據庫類型。Firebase僅提供NoSQL數據庫。

5.單個安裝包解決方案

AWS提供了你的應用程序可能需要的所有服務。因此，AWS是你可以完全依靠它來滿足所有需求的單一云解決方案。

如果你的整個后端都集中在一個地方，則更易于理解和維護。

• Firebase

1.專用數據庫

Firebase提供了兩種專用的數據庫服務：CloudFirestore和實時數據庫。

這兩個數據庫都是NoSQL數據庫，因此你不必擔心設置數據庫和編寫查詢來部署數據驅動的應用程序。

只要你的需求和要求很簡單，并且你知道將來它不會變得更加復雜，那么你可以使用NoSQL數據庫。

2.可調用函數

借助Firebase云函數，你可以創建云函數并通過URL設置觸發器來把監聽器寫入數據庫。

這些功能與AWSLambda相似，但是從應用程序觸發Lambda要求設置API網關并添加授權邏輯，這使其變得更加困難。

3.質量管理服務

Firebase提供了許多服務來監視和維護你的應用程序質量。其中一些服務如下所示：

• 動態鏈接：將用戶重定向到你應用中的正確位置，無論該應用是否已安裝。
• 遠程配置：使用服務器端配置自定義并嘗試應用行為。
• 測試實驗室：跨設備測試你的應用。
• 應用內消息傳遞：發送廣告系列來吸引用戶。
• 分析：幫助你計劃未來版本和用戶參與的策略。

• MLKit：將機器學習的功能添加到應用程序前端或后端的解決方案中。

4.平臺定價（AWS與Firebase）

這兩個平臺的價格都具有吸引力，甚至都提供免費套餐。因此，除非你擁有相當數量的活躍用戶，否則你無需付費。

• AWS

AWS掌握了其服務的定價，并以得便宜的價格提供了許多出色的服務。實際上，隨著時間的推移，他們已經能夠將其服務的價格降低80％以上。

這就是為什么你會發現大多數服務的AWS均比谷歌云服務提供商（GCP）便宜的原因。

為了構建實時應用程序，AWS提供了相對昂貴的DynamoDB。

對于云函數，AWS提供的服務價格是Firebase云函數的一半。

• Firebase

盡管AWS的某些服務價格便宜，但Firebase提供了一些完全免費的服務，例如：

• 用戶認證-使用等效于AWSCognito的FirebaseAuth。

• 推送通知-使用Firebase云推送等效于AWS中的簡單通知服務。

對于構建實時應用程序，與AWS相比，Firebase似乎便宜得多且易于安裝。Firebase負責其數據的實時同步，而你不必為此擔心。

隨著用戶數量的增加，Firebase顯然似乎是構建實時應用程序的更好選擇。

但是，如果你對查詢優化不夠謹慎，Firebase將收你30000美元。

順便說一句，在了解了發生了什么之后，Google放棄了一些案例。

某些東西比平臺定價還要貴。

時間和勞動力

這是需要考慮的重要因素，因為你將依賴資源來設置、構建和維護應用程序體系結構。

• Firebase

Firebase確實簡化了，使用起來非常簡單。前端開發人員實際上可以自己創建和維護整個后端，而只需了解一些有關設置方面的知識。

為了創建實時應用程序，Firebase解決了許多復雜性，并為你提供了非常強大且易于使用的SDK，為你節省了大量時間和金錢。

• AWS

由于AWS提供的服務是Firebase提供的服務的十倍，因此使用和維護它的復雜性也要十倍。而作者想說的是，與Firebase相比，AWS也有一些學習曲線。

為了創建實時應用程序，你需要使用GraphQLAPI以及DynamoDB實例（該實例又是NoSQL數據庫），但是你必須設置API和數據庫，這對于簡單的實時應用而言似乎有點過頭了。

總結

Firebase

• 容易設置、使用和維護。

• 要求你做出較少的決定，非常適合簡單的應用程序。

AWS

• 提供了更大的靈活性，這在構建大型和復雜的應用程序時有很大幫助，但對于簡單的應用程序可能會過大。

• 一個潛在的解決方案可以滿足你所有應用程序的需求，你可以構建一個整齊的包解決方案，但價格可能會更高。

希望這可以幫助你做出正確的決定，并在嘗試構建應用程序時提出更好的問題。

你對這兩種方式的體驗如何？歡迎評論告訴我們。

?兩成開發者月薪超1.7萬、算法工程師最緊缺！|中國開發者年度報告