[Solved] Can I Change Firebase Connection settings at runtime

Do all of your clients use the same schema in their database?

Not really for this project. Let me explain why:

As my projects handle a lot of “denormalized” data in Firebase, I created an application called “Firebase Surgeon” to speed up my projects in the design, testing and post-implementation phases (Some screenshots at the end of this post).

The idea was create a “Pocket Firebase Console” to facilitate the administration of the data, since the Firebase Console is not friendly on smartphones, and does not have functions such as renaming, copying or moving nested buckets or searching data throughout the database, just to name a few. And honestly, I don’t want to pay for a third-party product to have these basic functionality.

Looking at the satisfactory results I’ve gotten with this development so far, I see potential not only to extend the app’s functionality, but also to make it freely available to download at Play Store / Apple Store. My plans are to offer this app as a freeware (not open source) in gratitude for the great community support.

I also have plans to improve advanced features like automatic data generation, data import/export, data conversion to other formats turning the tool into a true Swiss Army knife for developers.

But… As in Thunkable the Firebase connection is “hardcoded” in the project properties, it is impossible to publish the application on the Google Play Store or Apple Store, as each user needs to connect the tool to different databases according to their needs /projects . So the only way nowadays would be to provide the tool as an open source application.

That’s why after found this post I asked if there are plans to have the Firebase connection setting available to be changed at runtime.

Can you help me to influence the staff to implement this feature in Thunkable in the near future?

Regards,

Paulo Vaz

2 Likes

Check this
https://x.thunkable.com/projectPage/619e8d851d818001049945c2

This is only the login portion but the idea is to use Firebase without having to hardcode the API and the Database URL.

Have Fun Thunking.

Hi @muneer!

This is fantastic!

But…

The current RealtimeDB Get and Save blocks and the cloud variables will not work with this approach… It means that it would be necessary to rewrite all the read and write routines to do via API, right?

If so, it’s honestly like reinventing the wheel, other than the time spent just to have this free tool working for other people than me…

I’d rather invest that time in deploying more advanced features like automatic data populating, exporting to other formats, import JSON files among other things…

Isn’t easier if the staff “opens” the connection setup to be changed at runtime?

Anyway, as usual you always show us different ways to obtain what natively we don’t have in Thunkable! I really appreciate your kind attention!

Regards,

Paulo Vaz

2 Likes

This is the easiest part.

The URL of your API is the Database URL part + the bucket or the path to your required key + .json

Do this and you will get the JSON value of that key.

You don’t really lose any thing, you will replace the DB Get block with API block using a simple 3 part URL.

@jared had shared the planet names from his Firebase account using this

https://jared-gibb-project-123-default-rtdb.firebaseio.com/.json

See this link

2 Likes

Hmm… I got “Code: 400 || Message: EMAIL_NOT_FOUND” when previewing this with my Firebase console email address.

1 Like

@tatiang, I can’t login either… but first, “wrong password”, and now “too many attemps to connect try later”

I will keep trying…

Sure @muneer if I move my app to use the Firebase API I get powerful features and more control over data manipulation, witch is very desirable for an APP like this.

The best reason I would consider this change is because it “seems” like we can control the amount of data loaded when reading a database in real time. And this is very useful, because in my application I do a “full node read” every time the user changes the path, to fill the Listviewer with Firebase data, identifying when it is an object or a simple value.

And at the root level ("/"), or any child node you can have literally Gigabytes to read and transpose into device memory. So if you “page” the data, you’ll of course save loading time, and you’ll also save money since Google charges you for the data traffic you generate. To avoid this constant reads I’m thinking in use a “listener” to detect changes to save time and data traffic (maybe my next implementation in the project).

But to be absolutely honest, I still don’t have the knowledge and time right now to spend on this low level development, and as I’m not familiar enough with this API, I’d have to study it, as I’ve never done anything like this (in fact, there are a lot of things that I never did and I’m learning thanks to you).

Thinking out loud, maybe if we do collaborative development on this tool, when it’s ready we could make it available for free (with ADs for the unpaid version). If anyone is up for the idea, I’ll be happy to share the project, and do this partnership.

Or, simpler than that, if @Thunkable_Staff opens the Firebase connection configuration (this was my first request), I would already be able to release the tool in the app stores.

1 Like

See all the features for the user authentication here

Not only this, many developers in the platform forgot that these blocks provided to read data from and write data to Firebase do not work by themselves and this block simplicity means there are servers on the side of Thunkable to receive your request and convert it to API calls or SDK library calls to get you the data.

In the unlikely event of these servers fail for one reason or another, your users will not be able to login to your Firebase services.

Let me surprise you more, I’m not talking about users testing your app using Thunkable companion app, I’m talking about users who downloaded and installed your app from App Store and Play Store.

Now, I’m not saying here that Thunkable servers will fail but just highlighting a fact that the simplicity of the blocks has a bottleneck behind it that very few developers consider.

1 Like

I fully agree!

And just remembering, I’ve seen Thunkable servers down a few months ago… Luckily it was a short outage (just a few hours), but imagine a mission critical app like the one I’m working on… An outage of just 1 hour will break all confidence in the product and severely impact the operation of the business (uber-like app).

Perhaps all this is an opportunity to learn and gain an extra level of independence, which is always welcome.

1 Like

In such situations, your app breaks not because of something wrong with the app but your app is using the Sign In / Sign Up blocks which rely on other servers to work making your app dependent on Thunkable servers even if your app is published.

1 Like

Exactly… When you develop your own database access/manipulation layer, connecting directly via Firebase API, you reduce the risks associated of this architecture, and get the advantage of a better data manipulation.

But of course, this is something very, very far from the “no-code” purpose of Thunkable, and not indicated for beginners like me, or for small projects…

But is something if I learn how to deal with, I will consider it to develop mission-critical apps in the future.

And of course for things like this, will be very welcome if Thunkable implements some missing features like Global Functions and a better organization in the variable access, among other improvements we as community are claiming.

1 Like

As far as I am aware, the calls are direct calls to the firebase endpoint and we do not proxy these calls. Do you have different information than this that would confirm the hypothesis?

Data calls I can confirm are currently proxied by Thunkable are for GSheets and Airtable only.

Scoped already and on the feature request board higher up than many other things!!

A quality of life improvement we have on our board!! (not sure where this one lies in priority)

[update]
@paulovaz72

here is an example that I made to handle this exact issue a while back. I just found it!
https://x.thunkable.com/projectPage/62265a9f1aadef00125058de

It’s certainly not pretty, BUT, you can hook into any firebase account dynamically (You’d probably need to refresh the webviewer. each time, but! it’s a start!

and here’s the HTML you’d need to include if you want to take a peek!


<html>

<head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src="https://thunkable.github.io/webviewer-extension/thunkableWebviewerExtension.js"
        type="text/javascript"></script>
    <script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-app.js"></script>
    <script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-auth.js"></script>
    <script src="https://www.gstatic.com/firebasejs/8.10.0/firebase-firestore.js"></script>
</head>

<body>
    <span id="messageDisplay"></span>
    <br />
    <button type="button" id="messageButton">Click to send a message to the app</button>

</body>
<script type="text/javascript">

    //when the page loads, get the message from the app and display it
    window.onload = function () {
        ThunkableWebviewerExtension.postMessage('ready');

    }

    ThunkableWebviewerExtension.receiveMessage(function (message) {
        //pass your firebase info here
        const configData = JSON.parse(message);

        firebase.initializeApp({
            apiKey: configData.apiKey,
            authDomain: configData.authDomain,
            databaseURL: configData.databaseURL,
            projectId: configData.projectId,
            storageBucket: configData.storageBucket,
            messagingSenderId: configData.messagingSenderId,
            appId: configData.appId,
            measurementId: configData.measurementId
        });

        // Initialize Firebase

        firebase.auth()
        var db = firebase.firestore();
    });

    // when we get a message from the app that needs a return value
    // return the string 'fast response' unless the message is
    // 'slow message'. If the message is 'slow message', wait for
    // four seconds, then return the string 'slow response'.
    // The slow response shows how this could work for API calls that
    // take time to execute.
    ThunkableWebviewerExtension.receiveMessageWithReturnValue(function (message, callback) {
        //login in to firebase
        const email = JSON.parse(message).email;
        const password = JSON.parse(message).password;
       
        firebase.auth().signInWithEmailAndPassword(email, password)
            .then((userCredential) => {
                callback(JSON.stringify({
                    message: 'success',
                    user: userCredential
                }));

            })
            .catch((error) => {
                callback(JSON.stringify({
                    message: 'error',
                    error: error
                }));
            })




    });
</script>

</html>
2 Likes

The issue reported in this post [Solved] All published Apps stop Working! Urgent help please! was effecting all and I myself was not able to login using the blocks but was able to login using the API endpoints.

I would stay away from a web viewer if I am targeting the independent run of the app from Thunkable server, I do not know for sure but it is issuing an iframe element which need to reside in a server.

A quick look through our codebase would indicate this is not the case, however I will check with @wei

He did post in that thread the items we are involved with, with no mention of firebase. I also asked this recently and was informed the same as below. which he reiterates here.

Typically, Firebase libraries manage the token for the user. I’m fairly certain the same happens here.

1 Like

Likewise, I’m certain I was not able to access Firebase at that time.

Whether it was this cause or any other cause, the result was the same. Something in Thunkable servers did not allow the process to complete. Why, I don’t know.

The answer given was not complete nor precise. It only gave examples and to be honest, I don’t know where Firebase components fit.

1 Like

I’ve pinged the engineering team and am waiting on a response! :slight_smile:

[Update]

Thanks for the great query here! It’s been confirmed by @paulmw

Thunkable apps implement a Firebase SDK to make calls directly to Firebase for both sign-in/sign-up blocks, cloud variables, and purple Firebase blocks (snapToPlace)

2 Likes

@jared please let us know, since you are a staff member, if exists any plans for now or for sometime in the future to “open” the Firebase Connection Settings @ runtime…

1 Like

This isn’t possible at the moment. My approach here, until something changes on our platform, would be to harness a service like xano to make these api calls on the backend for you and to return data to the device.

You could upload service keys and access your users data from the cloud. It is likely more secure than storing service keys on a device that may get found by an unwanted intruder.

You could get a jwt using the service key and hit up the Firebase API’s directly as such.

2 Likes