Part of the project goal was to explore Firebase. From what I see right now:

• Firebase auth looks bolted on. I understand the main point is having different login systems (google, email, etc.) and the Firebase server generates a unique user id for new users, trying to regroup them across login system (e.g. email vs google account.)
• The pro is having a single user id regardless of the authentication method.
• The obvious cons is the secondary server authentication lookup to convert the googler user id into a firebase user id.
• Pros: not having to implement it using my own app engine instance + db.
• The "realtime" database seems to work as promised. However:
• User compartmentalization is done at the app level and by server-side rules. It seems fragile in the sense that a programming error or a design flaw could possibly expose all data to all users.
• All user data is visible as-is in the console, with a limit of 500 users or similar. Search can be done by user id. That seems like a potential PII issue and at the same time not sure how much it can really scale. What happens with 1 million users?
• How much "realtime" is the database? I wasn't even able to sign-in on a low cell phone connection (vacation).
• Pros: not having to implement it using my own app engine instance + db.
• I did not try "remote app settings". That seems like a generalization of the realtime db readable by all apps. Maybe that's the point and just enough.
• I implemented the firebase analytics but I can't see the results yet, the console is quite unresponsive over a low cell connection.
• I don't see anything obvious that is an advantage over pulling google analytics, except it's one less library and in theory it's tied to firebase user ids.

Overall I'll have to defer to see how this behaves with a better connection.

I do have my concern with the speed of the firebase requests.

The other thing not so clear is how does that scale.

Overall I guess the point of Firebase is having to avoid implementing an extra app-engine backend server. If it were used in an application that requires such a service, then the point seems rather moot.

For example I started a project with the idea of having both Firebase and App Engine. I thought I needed app engine for the storage of users ACLs, themes, and live instances but I see these could be replicated in the Firebase realtime db using denormalized storage & rules. The other reason I wanted app engine was to have all the processing on the server and the web site to be merely a "dump" presenter (using the MVP distributed pattern) .

Using Firebase, it makes more sense to have all the logic client side, with only storage on the server side.

⇒ It turned out to be disappointing. One issue is the login time on the Android app. It takes several seconds (10-20 s?) for the app to authenticate via google auth then via firebase before it can do any queries.