AWS仍是Firebase？在移动应用后端应该使用哪一个？

做者| Dhananjay Trivedi

翻译 | 天道酬勤，编辑 | Carol

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

咱们将按如下顺序比较这两种服务：

1. 它们有什么共同点？

2. 如何将它们与你的前端集成？

3. 它们的优点。

4. 它们的价格。

5. 建立和维护所需的成本。

6. 最后的想法。

 

在咱们开始以前，做者想先声明一下，本文并不是要从二者中分出一个胜负，因此不管你是哪一方的忠实支持者，都建议你仅客观看待本篇文章。

由于今天咱们所讨论的核心问题是：“哪一个是适合你需求的解决方案？”

 

做者已经开发原生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提供了一些彻底免费的服务，例如：

1. 用户认证-使用等效于AWS Cognito的FirebaseAuth。

2. 推送通知-使用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

• 提供了更大的灵活性，这在构建大型和复杂的应用程序时有很大帮助，但对于简单的应用程序可能会过大。

• 一个潜在的解决方案能够知足你全部应用程序的需求，你能够构建一个整齐的包解决方案，但价格可能会更高。

 

但愿这能够帮助你作出正确的决定，并在尝试构建应用程序时提出更好的问题。

 

你对这两种方式的体验如何？欢迎评论告诉咱们。

 

《原力计划【第二季】- 学习力挑战》

正式开始

即日起至 3月21日

千万流量支持原创做者

更有专属【勋章】等你来挑战

推荐阅读：Spark大数据分布式机器学习处理实战 | 博文精选5亿整数的大文件，怎么排序 ？面试被问傻！
谁将称霸跨平台应用市场？程序员删库跑路不可防，可是这你应该防了......
深耕技术，与实践赛跑：一文告诉你如何稳妥快速完善区块链技术并有序推进商用？
大脑芯片公司Neuralink计划在人脑内植入芯片，他们到底想干什么？
真香，朕在看了！点击“阅读原文”，参与报名