@Bob, You might want to consider this Power Users board comment from MIT's Jeff Schiller on the future of Firebase before investing further into it ...
The purpose of this note is to clarify some facts about our support of Firebase.
We first integrated Firebase into MIT App Inventor when Firebase was a stand-alone company prior to its purchase by Google.
At that time Firebase offered a client side SDK for interacting with Firebase databases. This SDK was in the form of a collection of “Jar” files which worked on any Android platform. In particular it worked both on devices running Google’s flavor of Android and Amazon’s flavor, used on the Fire Tablets. Fire Tablets are quite popular in some environments and our ability to support Firebase on the Fire Tablets is an important feature.
Firebase offers several ways to authenticate the end-device to Firebase. In particular we used their “custom” authentication. This permitted us to have one Firebase account, run and paid for by MIT, that all could use without having the either pay money or even deal with an administrative setup process. You just put the component into your project and you had shared variables.
Of course we were concerned from the beginning that this might lead to a significant cost to MIT if usage was very high. However we took the risk, figuring we could also implement some mechanism to control our costs. This didn’t happen. Or more to the point, the cost of offering Firebase was not very significant compared to the cost of running the public service itself (Google used to help us pay for it, but isn’t currently. So we pay the public price for using App Engine). [Donations accepted :-) ].
Google purchased Firebase and has been integrating it into Google’s infrastructure. This has had two consequences.
- They no longer offer the client side SDK that we use in the Component. Instead they have made the Firebase API part of Google Play Services. However Google Play Services is not available on Amazon Fire devices.
- They appear to be deprecating the “custom” authentication we rely upon. The remaining authentication mechanisms require each developer to create (and pay) for their own account.
Firebase continues to work for us today because we are still using the now deprecated client side SDK that we downloaded from Firebase when they were an independent company. And, and this is a very important *AND*, the “wire” protocol used by Firebase has not changed, so the SDK continues to work. In other words, the way the bits are sent to Firebase (now Google) servers has not changed so the SDK we use still works.
However we may be living on borrowed time. At any time now Google may choose to “break” the wire protocol we rely on. When that happens the Firebase Component will quite suddenly break for everybody. The fact that the SDK is deprecated and no longer available as a stand alone package, means we are effectively on notice.
Updating the Firebase Component to use Google's supported API through Google Play Services will immediately mean that we will no longer support the Fire Tablet, not something we want to do. And although I believe as of today we may be able to kludge the use of "custom" authentication with the Google Play Services version, it is pretty clear that it isn't the direction Google is going in.
All of this is one of the risks one takes on when one chooses to use a proprietary infrastructure. There are plenty of cases where proprietary infrastructure, especially those provided by startup companies, have been shutdown. Sometimes on little notice.
This was one of our motivations for the CloudDB component. It is also the motivation of use choose an Open Source backend for CloudDB. The CloudDB server is based on the open source Redis project. MIT is providing the backend, but you can use your own Redis server if you wish. Most importantly, if you wish to develop an application that you really want to work over a long period of time, you can deploy your own Redis server and you are protected. This is not to say that MIT is planning on shutting down the server we provide. The point is you can protect yourself, even from us, by being in control of your own infrastructure. Similarly we are in complete control of the infrastructure we provide so we can be assured that we will not have to face the deprecation situation that we may face with Firebase.
I hope this helps explain things.