Will kodular continue to support firebase if MIT drops support?

I am putting a lot of time in to using Firebase. I have heard the App Inventor is deprecating Firebase. Will Kodular continue to support Firebase as an option for a NoSql database?

…As long as Google doesn’t kill Firebase

2 Likes

Thanks! Has Google indicated that they will be killing Firebase?

I hope they don’t kill it with water.

4 Likes

Or Waterbase…:joy:

1 Like

Firebase will be around us until Google don’t kill it and specially until @Sander don’t loose his determination

Where did you hear that? To my knowledge App Inventor is deprecating Fusiontable because Google is going to do that. I never heard of them deprecating Firebase.

1 Like

He probably understood it from app inventor:

1 Like

Firebase of Kodular and AI are very different. This is the standpoint of AI about the use of Firebase.

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 :slight_smile: ].

Google purchased Firebase and has been integrating it into Google’s infrastructure. This has had two consequences.

  1. 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.

  2. 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.

-Jeff

3 Likes

FusionTables users can relate

This helps quite a bit. I found CloudDB a little harder to deal with since there is no dashboard so you can see what your DB looks like but it does seem very similar to Firebase. I completely understand your point about Google. Thanks for the response.

Cliff

LOL​:laughing::joy: that is so funny

1 Like

Sorry for responding to an old topic but I think this can help some ppl.
You can use http://redsmin.com to manage your CloudDB. You can manage your redis-server and see all the tags.

1 Like