I’m using the realtime database for my Flutter app.
I’ve red on the Firebase website the db uses SSL encryption overhead. ~ 3.5kb
My app uses multiple listeners and does a lot of update operations. ~ 3 listeners and 50 updates per user session
Do I have to ‘pay’ 3.5kb with every operation?
Or is the ssl connection only once when the app is launched?
Thanks in advance !
Contacted firebase support about this:
"The Admin SDK for Node uses a socket to connect to the Firebase
database. It does not use the REST API. Bandwidth while negotiating
the HTTPS/WebSocket connection is billable traffic here too. The
building of this connection from Cloud Functions to the Database
happens when a new container is created. This can be upon the first
deployment of the project's functions, after a period of inactivity,
or when the Cloud Functions needs to be scaled-up due to high
activity."
Related
I was able to configure the Firestore database in Firebase with my flutter app and also create and read documents from my collection but when I go to Firestore console I don't see the created data, also when I creat data manually I am unable to see it in my application.
I am using the test mode which means any user can read or write.
I hope someone can help me with this puzzle.
Thanks!!!
It sounds like the device/emulator that you are running on is not connected to the internet, or at least not to the Firestore servers. In that case, the client writes all local changes into a local database, waiting to send them to the server when it gets a connection. So the local app will work, but won't be able to synchronize its local cache with the database servers.
You might want to check the connection on your device, and any proxies that might exist between your app and the Firestore servers.
Using
FirebaseDatabase.getInstance().setPersistenceEnabled(true);
Is this guarantee to download the data only one time across the App life/App restarts even if the user has good connection?
N.B: The official docs isn't clear ( at least for me) at this point.
By enabling persistence, any data that the Firebase Realtime Database client would sync while online persists to disk and is available offline, even when the user or operating system restarts the app. This means your app works as it would online by using the local data stored in the cache. Listener callbacks will continue to fire for local updates.
The sole goal of enabling persistence is to ensure that the app continues to work, even when the user starts it when they don't have a connection to the Firebase servers.
The client does send tree of hash values of its restored local state to the server when it connects, which the server then uses to only send the modified segments back. But there is no guarantee on how much data this sends or saves.
If you want to learn more about what Firebase actually does under the hood, I highly recommend enabling debug logging and studying its output on logcat.
For more on the topic, see these questions on Firebase's synchronization strategy.
I'm just getting started with the Firebase ecosystem and doing some investigating before committing to a GCloud database implementation (Datastore vs. Firestore). My target client is Web/browser and my backend services will be in AppEngine.
Tinkering with the cloud messaging quickstart example, it seems that FCM doesn't work in several scenarios (incognito mode, Safari, if permission blocked). However, the friendly chat demo that uses realtime db updates does appear to work in these scenarios.
High level could anyone explain why?
My goal is to subscribe to events for the client to update state, etc without the use of polling. It seems overkill to put these into firestore just to bypass the notifications permission requirements. Any insight is appreciated. These events could be dispatched from several different backend services and are not exclusively bound to db records.
Update
For what I wanted to do, I was able to simply use Firestore and had no needs that targeted specific devices that merited using FCM. Firestore came out of beta since I posted this question and works well for live subscribing to queries that update local state, which is ultimately what I needed to do.
The FCM client works on the promise that it can identify your browser, even when the page is not open. So it needs to persistently be able to identify the browser. It uses an Instance Token for that, which I assume it persists in the local storage of your browser. And since an incognito window has its own local storage, it becomes a separate instance ID.
The Firebase Realtime Database itself does not persist any information about the instance. Instead you pass in all the necessary information when you initialize the FirebaseApp instance, and then get a DatabaseReference. Since the incognito window runs the same code, it's accessing the same information in the database, and thus seeing the same result.
Note that this would be different if you use Firebase Authentication in combination with the Realtime Database. Auth will persist the user token to local storage, so that won't be shared with the incognito window.
My app run in background. If app run in background, is still simultaneous connected with realtimeDB? Or if this app doesn't use realtimeDB for a while, does not count simultaneous connected?
If it's count anyway, can I only get 100,000 user?
Your app is connected to the realtimeDB as long as your listener is active. If you want to stop listening you need to remove the listener according to your needs and to the activity cycle.
For Android you can use this code in your onDestroy() method.
databaseReference.removeEventListener(valueEventListener);
Hope it helps.
I am answering your three part question in order..,
Firebase database library manages the connection to your database in the backend and this starts right away at the start of the app and this starts counting against your simultaneous connections and when this limit reaches the Max Connections limit of 100k any new connections will be dropped until the existing connections drop by either closing the app or app goes offline after a specified time-out or forcefully closing the DB connections by calling
FirebaseDatabase.getInstance().goOffline()
You can however know the whether a given client is connected or not by using the listener at FirebaseDatabase.getInstance().getReference(".info/connected") this however works locally and doesn't explicitly connect to FirebaseDatabase cloud instance., more can be read here
Once you implement the above connection listener you will see that the SDK manages this dynamically in a way that the connections disconnect automatically if there are no listeners attached and if no DB operations like .setValue() are made in the app in last 60 seconds.., but the presence of ValueEventListners will override this and will ensure continuous connectivity with the DB. again this can be overridden and the connection can be severed by explicitly calling FirebaseDatabase.getInstance().goOffline()
Coming to the Max Limit of 100k simultaneous users; as can be seen in Firebase Plans
There is a limit of 100,000 simultaneous connections per database on
the Flame and Blaze plans. See Pricing FAQ for more information.
If you cross this and for scaling you need to increase the limit, you can explicitly ask Google Firebase Team for the support and they will handle this on a case by case basis to ensure your app can scale as required when required..
What is a "simultaneous database connection"?
A simultaneous connection is equivalent to one mobile device, browser
tab, or server app connected to the database. Firebase imposes hard
limits on the number of simultaneous connections to your app's
database. These limits are in place to protect both Firebase and our
users from abuse.
The Spark plan limit is 100 and cannot be raised. The Flame and Blaze
plans have a limit of 100,000 simultaneous connections per database.
If you need more than 100,000 simultaneous connections, contact
Firebase support.
This limit isn't the same as the total number of users of your app,
because your users don't all connect at once. We encourage you to
monitor your peak simultaneous database connections and upgrade or add
more databases if needed.
Can we implement Firebase for an android app, where I am registering user using Mobile number (Similar to Whatsapp). Users will be sent a code by server which is entered by user in android app to validate the user mobile number and registering him on the server.
Question : Can I use the above method in conjunction with Firebase Auth?
I was earlier going to use MongoDB for my project, but since Firebase has SYNC capabilities, it will be a better choice for storing data. Another good reason is as below:
If a client loses its network connection, your app will continue
functioning correctly.
Every client connected to a Firebase database maintains its own
internal version of any active data. When data is written, it's
written to this local version first. The Firebase client then
synchronizes that data with the remote database servers and with other
clients on a "best-effort" basis.
Very NEW to Firebase, just came to know about firebase (through Google 2016 IO).
https://firebase.google.com/docs/database/android/save-data
Firebase hosting is not for server side processing.
It stores static assets of your website as a world-class high availability CDN. So websites hosted here loads very fast. Even in high-availability scenarios.
So you have to do processing at other server which then connects with firebase and stores userinfo in realtime database.
Firebase has put limits on userinfo to be placed in directly for users auth dashboard.
For detailed userinfo, firebase realtime db is the way to go(from your processing backend to firebase realtime db).
Further Reading: What kind of web applications are Firebase not ideal for?