移动应用后端应该使用 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提供了一些完全免费的服务，例如：

• 用户认证-使用等效于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

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

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

希望这可以帮助你做出正确的决定，并在尝试构建应用程序时提出更好的问题。

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