Search code examples
google-app-enginefirebasegoogle-cloud-endpoints

Google App Engine vs Firebase


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?


Solution

  • 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):

    enter image description here

    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.

    EDIT 2022:

    Anyone considering Firebase should instead consider the new and improved Firestore. All of the above still holds true even for Firestore.

    In my original answer I said that Firebase might disappear the way Parse did. Although that has not happened, Firestore is definitely the replacement. In my opinion, Google should have built Firestore first. They already had datastore and I'm surprised they didn't just build on top of that. I'm sure it is easier said than done though.