Firebase Realtime Billing - Protocol and SSL overhead

Hi there,

I’m new at thunkable and I have to say thanks for all the community posts which helped me rapidly understand the building process. and may i say i came from trying other competitors and i can say that i finally found my favorite platform.

I have one concern in mind which is firebase realtime database billing, since i plan to use it exclusively for my project, and there will be a lot of read and write operations.

I already plan to minimize the read and write operations and use the stored variables as much as possible, while keeping the update from firebase to the needed minimum.

I saw in the firebase documentation that even though a chat message download could be 50 bytes, there are other factors for each read such as Protocol Overhead and SSL overhead which might add another 3.5 KB (if not more) which is insane, and they say to avoid that, your app would have to use native SDK to avoid multiple connections per user session which reduces those overhead costs.

Additionally, when using a native SDK instead of API then throughout the session of the app, the user would remain connected to firebase which would reduce reconnection and using SSL.encryption over and over for each read/write.

My question is this how are thunkable apps built when this is concerned? and by using cloud variables, is my thunkable app communicating with firebase through an SDK or a back-end API request?

Appreciate your helpful feedback.

1 Like

Welcome to Thunkable.

Apparently, your inquiry can only be answered by one of Thunkable developers not the community members. The good part is, @Thunkable_Staff visit the community regularly and you might get the answer quicker that expected.

I’m mentioning one of the Admins as he might know and also one of the staff to get you a quick response, if possible.

CC:
@tatiang
@jared

1 Like