Google App Engine vs Firebase

Question

I am trying to decide which option to go with. (or another if it is better) This is for a messaging type app where there will be high volume of notifications and database writes.

Option 1 - Google App Engine using Cloud Endpoints and Cloud Datastore
Pros:

• Able to build out an API the way I would like.
• Scalable

Cons:

• More work implementing a notification system. (Which will end up being Firebase Cloud Messaging)

Option 2 - Firebase
Pros:

• Able to use the Firebase Database, Firebase User Authentication, Firebase Cloud Messaging(notifications)
• Detailed use statistics for all devices
  

Cons:

• No API

Option 3 - Would it be possible to combine Google Cloud Endpoints and Firebase?

Answer 1

First off take a look at the chart here from the Google docs for a great comparison and contrast of the different mobile app backend services they offer. Here is the chart (Note: chart no longer appears on their site at that link):

My personal opinions are (Updated):

Option 1 - Google App Engine using Cloud Endpoints and Cloud Datastore
Pros:

• You will learn a lot more about the restful pattern writing your own API. You will also be forced to learn how to make restful api calls (either with iOS or Android) and that is a very valuable skill in the industry. Firebase sort of does everything for you and you won't ever learn this stuff.
• 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.
• What if Firebase goes the way of Parse.com... Where Facebook announced they won't be supporting it anymore. That would really suck! You would be locked in to Firebase and not have developed any programming knowledge on how to make a restful API. However due to Google's heavy investing in Firebase and now upgrading GCM to Firebase Cloud Messaging, it is clear they have big plans for Firebase and it is not going anywhere. So I don't think this counts as a "con" but keep it in mind?

Read more in the link for possibly combining them.

Answer 2

I'm puzzled that many discussions of Firebase (including the question and answer above) fail to mention what, to me, is a very important difference: price.

Here is the Firebase price schedule.

Here are the Datastore and GAE pricing.

It can be tricky to compare these, but my interpretation is that Firebase is very expensive.

And this should come as no surprise. GAE and datastore have to compete with similar services from Amazon, Microsoft etc., and the competition is fierce. Yes, these services are not as generic as infrastructure and SQL, of course, but they seem to be close enough that the prices remain competitive.

Firebase, on the other hand, is a premium service that competes with other backend services like Parse, and once you decide to use it I think it would be very difficult to switch. It should come as no surprise that Google is pushing Firebase so hard - they are probably going to make a ton of money off of it since they can price it at such a premium.

In my opinion, the upshot of this is that Firebase is a good choice for low volume and high-margin services, but if you plan to create a typical, consumer oriented, ad supported service that would depend on large volume to make money, then the cost of Firebase may kill your profit.

2017-10 Addition:

I looked at Firebase again with the recent release of Firestore.

I think it is important to be aware of another issue: using Firestore for an Android app means using the Firebase client library which is heavily dependent on Google Play Services, which means you can't deploy to non-Google devices including Amazon Fire tablets and (I believe) the entire Chinese market.