Google App Engine与Firebase

首先来看看图表这里从谷歌文档为一个伟大的比较和它们提供的不同的移动应用后端服务的对比。图表如下：

我的个人意见是（更新）：

选项1-使用Cloud Endpoints和Cloud Datastore
Pro的Google App Engine ：

• 您将学到更多有关编写自己的API的宁静模式的信息。您还将被迫学习如何进行宁静的api调用（使用iOS或Android），这是该行业中非常有价值的技能。Firebase会为您做所有事情，您将永远不会学到这些东西。
• You have to write it yourself, but you can get really creative with your API methods and Google Cloud Messaging and the type of methods you create. They can really do anything and connect to any database too (e.g. MySQL, SQL Server, Datastore). In Firebase you must use their json based database. I don't recommend using a SQL database for an app but different people have different needs.

Cons:

• It takes more work and wrapping your head around datastore can be hard at first. It is not like a relational database like SQL.
• Also I feel there are a few areas where you can "shoot yourself in the foot" by creating methods and queries that are very inefficient and thus take a long time to run.
• One thing that is annoying for new apps is the automatic-scaling in GAE. Long story short, if no one hits your API for about 15min then all instances are shut off. Once a new call is made, it takes a significant amount of time to fire an instance back up, and execute your API method. This can be annoying for new apps because new users might thing there is something wrong with the app and thus the may stop using it. You can do manual-scaling but then that costs money to have an instance on all the time (as of this writing around $27/month from my billed apps). See my post here for more information on this issue and a solution I came up with.

Option 2 - Firebase
Pros:

• It is made to be easy to use for beginners and there are ample tutorials/courses on Firebase to do those popular things you want to do like send push notifications and sync data.
• Unlike GAE, it is fast out of the box. No firing up instances. This makes it great for new apps that want to impress users with their fast data gets.
• You can get around learning the nitty gritty of complicated things like adapters (Android) and networking (in mobile apps) and just rely on the Firebase classes. Maybe it is a little more noob friendly? Again, the documentation is great and out-of-the-box I think there are less chances to shoot yourself in the foot by writing inefficient queries.
  

Cons:

• Firebase is heavy on client code. If you want an Android and an iOS app you have to write a lot of client code for both. In GAE, a lot of that logic is abstracted away in the GAE app. But this could be an advantage if you don't really want database admins in your app and just have iOS + Android developers who know Firebase. But for me this was the big turn off.
• 如果Firebase取代了Parse.com，该怎么办... Facebook宣布不再支持它。那真的很烂！您将被锁定在Firebase上，还没有开发任何有关如何制作一个宁静的API的编程知识。但是，由于Google对Firebase的巨额投资以及现在将GCM升级到Firebase Cloud Messaging的原因，很明显，他们为Firebase制定了宏伟的计划，而且计划一事无成。所以我不认为这是“骗局”，但要牢记在心吗？

在链接中阅读更多内容，以将它们组合在一起。