Realtime: Firebase or Manual Node.JS Socket Servers?

[Kaan Soral]

For realtime stuff, I normally use Node.JS servers, and persist/back-up data to App Engine, however, the scaling, spinning up the servers are always manual for me, it's also not easy dealing with server exceptions when they happen

I'm wondering whether using Firebase is feasible for basic multiplayer games, for example chess, where 200-300ms of delays don't affect gameplay (but 1-2 seconds of delays are still not acceptable)

Reading this: https://cloud.google.com/solutions/using-firebase-real-time-events-app-engine - Gave me hope

But after that, I dived into this: https://github.com/firebase/firebase-functions/issues/4 - Which made things a bit confusing, as local testing seems possible, but not trivial

This further complicated things: https://firebase.google.com/docs/firestore/rtdb-vs-firestore

Now the questions in my mind are:

1) Can I use Firebase?

2) Firebase or Cloud Firestore?

3) Can I test and develop for these locally?

Not exactly an App Engine question, but at heart, it's an App Engine question, as I want things to be as seamless as possible and go along with App Engine as best as possible

[Kaan Soral]

To iterate a bit on my question, It seems I'm intending to use "Firebase Realtime Database", which is a different thing than the new Firestore, since Firestore is similar to Datastore, I initially had the impression that it was Firebase merged into App Engine, but it's not, it's the NoSQL version of the Realtime one

The second link I shared is for the "Cloud Functions", so my remaining questions are:

A) Is there an SLA / Guaranteed reliability for Realtime Database of Firebase? (As far as I read, it delivers on it's promise tho)

B) The local testing and local setup aspect, I couldn't figure it out just yet

[Nick]

Firebase is great - this is exactly the right problem space for it. App engine is not really a good fit at all (eventual, so-so performance, no real time support).

Firebase doesn’t have SLAs around response times etc, but we’re talking very low latency, so even if it was 1/100th of it’s typical rates it’s still going to be faster than an app engine rest request (especially one involving spinning up a new instance).

Fire store seems to basically be a management API over the data store. That is it handles consistency, indexes etc. Note that right now you cannot use firestore on a GCP project that has GAE or the datastore enabled.

Firebase + GCF is the best option on GCP (and any other platform I’d say) for a semi-real time game if you don’t want to manage infrastructure. Your only barrier is what to do after you have more than 100k concurrent users.

[George (Cloud Platform Support)]

Hello Kaan, 

Real-time gaming is a possible area of efficiency for Firebase, so 1) and 2) You can use Firebase. 3) You can "Run Functions Locally", as described on the similarly named page. 

For more insight, you can read an excellent example on the "Using Firebase for Real-time Events on App Engine" documentation page. 

[Kaan Soral]

After dealing with Firebase for 2 days, my conclusion is that the grass is greener on the App Engine side

We have our well defined app.yaml's, perfect CLI's, full local emulation

I don't think the "Firebase" command emulates https://databaseName.firebaseio.com locally

Basically, I'm trying to just use Firebase for the realtime App Engine to Client communications, instead of polling, App Engine is going to update the Firebase Realtime Database instead, however, if the Firebase Realtime Database isn't emulated locally, can't develop anything practically

Not really the place for this discussion, but a good opportunity to appreciate our App Engine workflow