我正在尝试决定使用哪个选项 . （或者如果更好的话，则为另一个）这适用于消息类型的应用程序，其中会有大量的通知和数据库写入 .
Option 1 - 使用 Cloud endpoints 和 Cloud 数据存储的Google App Engine
优点：
-
能够按照我想要的方式构建API .
-
可扩展
缺点：
- 实施通知系统的更多工作 . （最终将成为Firebase Cloud 消息传递）
Option 2 - Firebase
优点：
-
能够使用Firebase数据库，Firebase用户身份验证，Firebase Cloud 消息传递（通知）
-
所有设备的详细使用统计信息
缺点：
- 没有API
Option 3 - 是否可以将Google Cloud Endpoints与Firebase结合使用？
3 回答
首先，请查看Google文档中的图表here，以便对他们提供的不同移动应用后端服务进行比较和对比 . 这是图表：
我的个人意见（更新）：
Option 1 - 使用 Cloud endpoints 和 Cloud 数据存储的Google App Engine
优点：
您将学习更多关于编写自己的API的restful模式 . 您还将被迫学习如何进行宁静的api调用（使用iOS或Android），这是业内非常有 Value 的技能 . Firebase类似于为您完成所有事情，您将永远不会学到这些东西 .
您必须自己编写，但您可以通过API方法和Google Cloud Messaging以及您创建的方法类型获得真正的创意 . 他们可以真正做任何事情并连接到任何数据库（例如MySQL，SQL Server，Datastore） . 在Firebase中，您必须使用基于json的数据库 . 我不建议为应用程序使用SQL数据库，但不同的人有不同的需求 .
缺点：
这需要更多的工作，并且最初可能很难将数据存储包围起来 . 它不像SQL这样的关系数据库 .
此外，我觉得有一些领域可以通过创建非常低效的方法和查询来运行，因此需要很长时间才能运行 .
对于新应用而言，令人讨厌的一件事是GAE中的自动缩放 . 长话短说，如果没有人在大约15分钟内点击你的API，那么所有实例都会被关闭 . 一旦进行了新的调用，需要花费大量时间来备份实例并执行您的API方法 . 这对于新应用程序来说可能很烦人，因为新用户可能会对应用程序出现问题，因此可能会停止使用它 . 你可以进行手动缩放，但是这需要花钱才能有一个实例（从我的账单应用程序开始，每月约27美元/月） . 在这里查看我的帖子，了解有关此问题的更多信息，并提供了solution .
Option 2 - Firebase
优点：
它对初学者来说很容易使用，并且有很多关于Firebase的教程/课程来做你想要做的那些流行的事情，比如发送推送通知和同步数据 .
与GAE不同，它开箱即用 . 没有启动实例 . 这使得它非常适合希望通过快速数据获取用户的新应用 .
你可以到处学习适配器（Android）和网络（在移动应用程序中）这些复杂事物的细节，只需依靠Firebase类 . 也许这是一个更友善的诺布？再一次，文档是伟大的，开箱即用我认为通过编写低效的查询来拍摄自己的机会较少 .
缺点：
Firebase对客户端代码很重视 . 如果你想要Android和iOS应用程序，你必须为它们编写很多客户端代码 . 在GAE中，很多逻辑都在GAE应用程序中被抽象出来 . 但如果你真的不想在你的应用程序中使用数据库管理员并且只有知道Firebase的iOS Android开发人员，这可能是一个优势 . 但对我来说，这是一个很大的转折点 .
如果Firebase走上Parse.com的道路......如果Facebook宣布他们赢得了对Firebase的大量投资并且现在将GCM升级到Firebase Cloud 消息传递，很明显他们对Firebase有很大的计划，而且它无处可去 . 所以我认为这不算是一个"con"而是记住它？
阅读链接中的更多信息，以便将它们组合起来
我很困惑，很多关于Firebase的讨论（包括上面的问题和答案）都没有提到对我来说是一个非常重要的区别：价格 .
这是Firebase price时间表 .
这是Datastore和GAE价钱 .
比较这些可能很棘手，但我的解释是Firebase非常昂贵 .
这应该不足为奇 . GAE和数据存储必须与来自亚马逊，微软等的类似服务竞争，竞争非常激烈 . 是的，这些服务当然不像基础设施和SQL那样通用，但它们似乎足够接近，价格仍然具有竞争力 .
另一方面，Firebase是一种优质服务，可与其他后端服务（如Parse）竞争，一旦您决定使用它，我认为切换非常困难 . 谷歌如此努力地推动Firebase应该毫不奇怪 - 他们可能会从中赚取大量资金，因为他们可以以如此高的价格定价 .
在我看来，这样做的结果是Firebase是低容量和高利润服务的不错选择，但是如果你打算创建一个典型的，面向消费者的，广告支持的服务，这将取决于大量赚钱，那么Firebase的成本可能会损害您的利润 .
2017-10 Addition ：
我最近发布的Firestore再次查看了Firebase .
我认为重要的是要注意另一个问题：将Firestore用于Android应用程序意味着使用严重依赖于Google Play服务的Firebase客户端库，这意味着您无法部署到非Google设备，包括Amazon Fire平板电脑和（我相信）整个中国市场 .
我最近学到的一件事是，我正在努力寻找解决方案，因为firebase不提供任何有关设备到设备通知的工作;虽然它确实提供服务器到设备推送通知，但它很容易设置 . 但前者缺乏功能是非常重要的，并且有一个阴谋论，因为他们试图推动你使用其他谷歌产品 .
或者，也许，因为它最初没有开发，所以它们保持不变 . 我认为app引擎是为此目的连接firebase和设备的一种方式，所以我倾向于将firebase和其他谷歌产品结合在一起app engine . 如果您计划进行更多的后端处理（如图像处理等），那么您肯定会查看app engine and compute engine哪些可以与Firebase集成，从而产生一个假设强大的后端解决方案 .