作者 | Dhananjay Trivedi
翻譯 | 天道酬勤，編輯 | Carol
出品| CSDN雲計算（ID：CSDNcloud）
我們將按以下順序比較這兩種服務：
它們有什麼共同點？
如何將它們與你的前端集成？
它們的優勢。
它們的價格。
創建和維護所需的成本。
最後的想法。
在我們開始之前，作者想先聲明一下，本文並非要從兩者中分出一個勝負，所以無論你是哪一方的忠實支持者，都建議你僅客觀看待本篇文章。
因為今天我們所討論的核心問題是：“哪個是適合你需求的解決方案？”
作者已經開發原生Android應用程序已有一段時間了，並且最近開始在Flutter中開發移動應用程序，並且同時將Firebase和AWS用作後端服務。
但是作者最近不得不為移動應用程序尋找解決方案，實際上作者花了很多時間來決定後端的正確服務。
因此，作者在這裡與大家分享他的觀點和理解，來幫助你選擇合適的服務而不會浪費很多時間。
這些服務有什麼共同點？
核心功能如下：
驗證碼
推送通知
存儲
託管
分析工具
所有這些都提供了，因此你可以使用這些平臺中的任何一個輕鬆地部署無服務器解決方案。
你如何將後端與應用程序集成？
集成這些服務的最流行方法是使用它們的SDK，但這是否符合你的需求？
- Firebase
Firebase提供了適用於Android、iOS和Web的SDK，因此，你作為前端開發者，實際上可以輕鬆構建數據驅動的應用程序，而不必依賴後端技能。
Firebase還具有一個REST API，你可以在想要構建自己的自定義API（根據自己的需求）時使用。
- AWS
AWS為移動開發者提供了一個非常不錯的解決方案，稱為AppSync，你可以將其集成到Android、iOS和React Native中。
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
適用於移動應用程序的AWS Amplify SDK與GraphQL和Apollo緊密集成。
4.數據庫的選擇
你可以完全控制要在後端使用的數據庫類型。Firebase僅提供NoSQL數據庫。
5.單個安裝包解決方案
AWS提供了你的應用程序可能需要的所有服務。因此，AWS是你可以完全依靠它來滿足所有需求的單一雲解決方案。
如果你的整個後端都集中在一個地方，則更易於理解和維護。
- Firebase
1.專用數據庫
Firebase提供了兩種專用的數據庫服務：Cloud Firestore和實時數據庫。
這兩個數據庫都是NoSQL數據庫，因此你不必擔心設置數據庫和編寫查詢來部署數據驅動的應用程序。
只要你的需求和要求很簡單，並且你知道將來它不會變得更加複雜，那麼你可以使用NoSQL數據庫。
2.可調用函數
藉助Firebase雲函數，你可以創建雲函數並通過URL設置觸發器來把監聽器寫入數據庫。
這些功能與AWSLambda相似，但是從應用程序觸發Lambda要求設置API網關並添加授權邏輯，這使其變得更加困難。
3.質量管理服務
Firebase提供了許多服務來監視和維護你的應用程序質量。其中一些服務如下所示：
動態鏈接：將用戶重定向到你應用中的正確位置，無論該應用是否已安裝。
遠程配置：使用服務器端配置自定義並嘗試應用行為。
測試實驗室：跨設備測試你的應用。
應用內消息傳遞：發送廣告系列來吸引用戶。
分析：幫助你計劃未來版本和用戶參與的策略。
ML Kit：將機器學習的功能添加到應用程序前端或後端的解決方案中。
4.平臺定價（AWS與Firebase）
這兩個平臺的價格都具有吸引力，甚至都提供免費套餐。因此，除非你擁有相當數量的活躍用戶，否則你無需付費。
- AWS
AWS掌握了其服務的定價，並以得便宜的價格提供了許多出色的服務。實際上，隨著時間的推移，他們已經能夠將其服務的價格降低80％以上。
這就是為什麼你會發現大多數服務的AWS均比谷歌雲服務提供商（GCP）便宜的原因。
為了構建實時應用程序，AWS提供了相對昂貴的DynamoDB。
對於雲函數，AWS提供的服務價格是Firebase雲函數的一半。
- Firebase
儘管AWS的某些服務價格便宜，但Firebase提供了一些完全免費的服務，例如：
用戶認證-使用等效於AWS Cognito的FirebaseAuth。
推送通知-使用Firebase雲推送等效於AWS中的簡單通知服務。
對於構建實時應用程序，與AWS相比，Firebase似乎便宜得多且易於安裝。Firebase負責其數據的實時同步，而你不必為此擔心。
隨著用戶數量的增加，Firebase顯然似乎是構建實時應用程序的更好選擇。
但是，如果你對查詢優化不夠謹慎，Firebase將收你30000美元。
順便說一句，在瞭解了發生了什麼之後，Google放棄了一些案例。
某些東西比平臺定價還要貴。
時間和勞動力
這是需要考慮的重要因素，因為你將依賴資源來設置、構建和維護應用程序體系結構。
- Firebase
Firebase確實簡化了，使用起來非常簡單。前端開發人員實際上可以自己創建和維護整個後端，而只需瞭解一些有關設置方面的知識。
為了創建實時應用程序，Firebase解決了許多複雜性，併為你提供了非常強大且易於使用的SDK，為你節省了大量時間和金錢。
- AWS
由於AWS提供的服務是Firebase提供的服務的十倍，因此使用和維護它的複雜性也要十倍。而作者想說的是，與Firebase相比，AWS也有一些學習曲線。
為了創建實時應用程序，你需要使用GraphQL API以及DynamoDB實例（該實例又是NoSQL數據庫），但是你必須設置API和數據庫，這對於簡單的實時應用而言似乎有點過頭了。
總結
Firebase
容易設置、使用和維護。
要求你做出較少的決定，非常適合簡單的應用程序。
AWS
提供了更大的靈活性，這在構建大型和複雜的應用程序時有很大幫助，但對於簡單的應用程序可能會過大。
一個潛在的解決方案可以滿足你所有應用程序的需求，你可以構建一個整齊的包解決方案，但價格可能會更高。
希望這可以幫助你做出正確的決定，並在嘗試構建應用程序時提出更好的問題。
你對這兩種方式的體驗如何？歡迎評論告訴我們。
閱讀更多 CSDN 的文章
