Downtime fallback

[Jonas Svensson]

Hi,
I'm in a team that evaluating firebase, and we for now using the free plan.

We experienced some downtime yesterday (20-01-2016). And I'm looking for a fallback when this occurs again.

I don't know which server I was connected to (is there a way to determine this?).

When I compare some statues, it seems not all servers was down.
Example: http://status.firebase.com/1598243/2016/01 and http://status.firebase.com/1784064/2016/01

Is it possible to choose another server if the connection get refused or when we receive a internal server error?
Or is it possible to for you to reroute the incoming requests to the server that is down to another server?

Cheer Jonas

[Jacob Wenger]

Hey Jonas,

At this time, you have no control over the server you are assigned to. If we have problematic servers (aka servers which have noisy neighbors, a hardware issue, or some other regular downtime), we will move all customers over to a new server and take that server out of rotation. Other than that, it is faster for us to get your server up-and-running than to switch you to a new server.

Thankfully, the downtime we saw yesterday which affected a handful of servers is not the norm. You can see historical uptime numbers at http://status.firebase.com to prove this.

You can find the server you are on by visiting https://<YOUR-FIREBASE-APP>.firebaseio.com/.settings/owner.json.

You can always reach out to firebase...@google.com if you'd like to talk about your specific case in more depth.

Cheers,
Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fb66e707-3313-4c45-8293-d4c2d41de07e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ivan Nincic]

Hi Jonas,

I have the same concerns. firebase claims reliability and scalability yet we are connecting to individual servers which are going down and are becoming unavailable. I am concerned whether firebase is currently suitable for real-world. Comments from the team would be appreciated.

Ian

[Tyler Snyder]

I'm also interested in an answer to this question.

Not only am in handling a lost connection to the DB, but also if my Firebase Hosting server goes down, what is the best way to be alerted of this? I'm would think onDisconnect() would not be useful in this scenario if my app can't even be served to a client.

Is there any more elegant solution than polling your status page and sending an email alert?

Thanks

[Piotr Kaminski]

Not an official response, but regarding Firebase Hosting:  they're currently reselling Fastly, which is pretty reliable in my experience.  I've mostly run into (rare) issues with the 'firebase' command-line deployer and the config file.  I use a free StatusCake config to ping a few pages on my site every 5 minutes just in case, though.

I second the concerns about server reliability.  I'm worried that even scheduled upgrades require bringing the servers down.  And the Firebase status page is not a good indicator of actual availability -- I've had my app effectively go down repeatedly (usually for a few minutes at a time) due to bogus throttling, Firebase regressions, etc., while the server's status stayed green.  Props to their support folks for responding quickly and working with me to hunt down the issue each time, but still.  In the end, Firebase is definitely more reliable than a hand-rolled solution and good enough for real world apps, but when something goes wrong you have very few tools you can use to investigate and fix the problem.

    -- P.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e7876d42-eebf-4452-86ec-bc9afc631b41%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

  Piotr Kaminski <pi...@ideanest.com>

  "That bun is dirty.  Don't eat that bun."

[Frank van Puffelen]

Thanks for all the feedback guys. See James' response here: https://groups.google.com/forum/#!topic/firebase-talk/XdrjTvtcWmY

[Jonas Svensson]

Hi Jacob,

Thanks for your reply. 

First I want to say that our team love to work with firebase. We can improve our products greatly with firebase.

I know that nothing can have 100% uptime, incident do happens. That is why I'm looking for a fallback solution.

Our backend that writes to firebase are aware of the downtime, but not our mobile clients that reads the data.

There is no problem for us to get the data from another source then firebase as fallback, it's just matter of when we need to do that.

For now, we will just tell our clients that we won't guarantee 100% uptime of the realtime data. No problem.

I'm now just elaborating with some possible solutions.
Is it possible to push a status flag to the affected clients when there is an incident?
Like have a service that monitors the servers and alerting the connected clients of outtakes.

Cheers Jonas

[Andrew Lee]

Hi Jonas -

If you want to track the uptime of your Firebase database from your end, I'd suggest using a service like Pingdom.

This doesn't notify your clients that the server is down. However, I don't know that you'll find any good solution there, since the vast majority of the time, if your client is unable to connect to our service, it is because of the client's network connection -- not downtime on our side.

I think your best "fallback" here, whether the downtime is caused by the clients network connection (common) or our downtime (rare), is to use our offline featureset. Firebase SDKs are designed to work and remain responsive even with no network connection.

Here's the iOS guide for offline:

https://www.firebase.com/docs/ios/guide/offline-capabilities.html

best -

-Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d3087f2a-dc07-45ee-b7e2-e85a38b9ac34%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrew Lee | Firebase Cofounder | and...@firebase.com | (805) 426-9663 

[Piotr Kaminski]

On Fri, Jan 22, 2016 at 9:32 PM, Andrew Lee <and...@firebase.com> wrote:

I think your best "fallback" here, whether the downtime is caused by the clients network connection (common) or our downtime (rare), is to use our offline featureset. Firebase SDKs are designed to work and remain responsive even with no network connection.

This is technically true, but between the default last-write-wins semantics, lack of control over the offline operation queue, and no long-term local persistence in the JavaScript SDK, in practice having a web app work offline for more than a minute or two is not feasible.  (Though of course this greatly depends on the nature of the app...)  Fingers crossed that the Firebase team will make some improvements in this area this year!

    -- P.

[Andrew Lee]

We hear you Piotr, and we're working on it. Stay tuned.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CANF_M5yLFNK3sSCt5c-srQrE4ROwUA3scpBwtog9_rVYhmvptQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.