I am attempting do the following
write a document to server.
wait for the success event and check for metadata to confirm if its written to server
if it is not written to server even after the time out (using a timer) undo the write operation.
this is for WEBRTC calls so if a user attempts a call but was offline and closes the app since it did not succeed. after a long time the receiver would receive a call and would be weird.
There are no undo operations in Firestore. The client SDK tries doesn't really give any way to discern if the app is online or offline - it simply tries its best to service the requests that you give it via the API.
If you want to perform some operation while only online, then use Cloud Functions to make an HTTP request to backend code that performs the actions you want. If the app is offline, the HTTP request will obviously fail, and you can decide what you want to do from there.
Related
I understood Firebase Storage not to have offline capability (because of open git requests for the feature and no mention of it in documentation) but I appear to observe it. When the client is offline and I attempt to get data from Storage, the return closure is expectedly not called. However, when the client comes back online, that closure is immediately called (returning the file from Storage), which appears to suggest that the request to get data was cached when the client was offline. Is this indeed the case?
There is no caching, but the SDK will retry with the hopes that a future request will succeed.
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.
In an interesting blogpost about 'Firebase Authentication with the Firebase 3.0 SDK and Auth0 Integration', it is stated that:
You can even have Firebase communicate with Webtask!
Now I can imagine the (web)client triggering a Firebase operation and subsequently a Webtask, but not the other way around. Or am I missing something?
Firebase can run as a serverless app, but it can also run on the server. You can even have Firebase communicate with Webtask! (sic!)
I think that paragraph is misleadingly phrased, perhaps it was just added at the last minute to spark interest. You can have a webtask communicate with Firebase, not the other way around. You don't "run Firebase" on your server either.
TL;DR: A client application may call a webtask with an HTTP request, and that task can read/write the database, but not in any other order.
Here's a quick and dirty reality check as of Nov. 2016:
The Realtime Database by itself does not provide you with a way of executing code. This includes responding to database changes and user requests, handling fan-in and fan-out operations, etc. There is no support for webhooks either.
Which means you have to provide your own execution environment for such logic on a custom server, or you can try to cram as much as possible into the client code. This is a pretty exhaustive topic by itself.
Webtasks are short-lived functions that respond to HTTP requests. Their lifecycle always starts with a request, so they are not fit for continuously watching the database for changes. But they are perfectly valid for handling requests coming in from your client application.
As you can store "secrets" for the webtasks, you can authenticate the task on an admin access level. This gives you the possibility to verify client tokens – which should be sent along with the request –; perform complex authorization and validation, and perform RTDB write operations you wouldn't trust the clients with.
Or trigger external services securely. The possibilities are close to endless.
I have an ASP.NET website with a a number of long-running (5 mins to 2 hours) user-initiated tasks. I want each user to be able to see the progress of there own jobs, and be able to close their browser and return at a later time.
Current plan is to store each job in the database when it's started and publish a message to a RabbitMQ queue, which a windows service will receive and start processing the job.
However, I'm not sure of the best way to pass the progress information back to the webserver from the service? I see two options:
Store the progress information in the database, and have the web-app poll for it
Have a RabbitMQ consumer in the webserver and have the windows service post progress messages to that queue
I'm leaning towards the second option, as I don't really want to add more overhead to the database by regular polling / writing progress info. However, there are lots of warnings about using RabbitMQ (as a consumer) - as I am not sending vital messages (it doesn't matter if progress messages aren't processed), I'm wondering if this matters? It's not that (famous last words) difficult to restart the RabbitMQ consumer whenever the web app is restarted.
Does that option sound reasonable? Any better choices out there?
Store the progress information in the database, and have the web-app poll for it
Have a RabbitMQ consumer in the webserver and have the windows service post progress messages to that queue
the correct answer is C) All Of The Above!
A database is not an integration layer for applications.
RabbitMQ is not meant for end-user consumption of messages.
But when you combine RabbitMQ with a database, you get beautiful things...
have your background service send progress updates through RabbitMQ. the web server will listen for these updates and write the new status to the database. use websockets (signalr) to push the progress update to the user immediately, but you still have the current status in the database in case the user does a full refresh of the page or comes back later.
i wrote about this basic setup in a blog post on using rabbitmq to do user notifications
I've been doing some research about secure tokens and Firebase JS, but I have ready some conflicting information, so I will just ask my question directly. Is it possible to handle secure sessions with Firebase using Javascript? For practice, I'm creating a little web game that will rely on Firebase to synchronize each client, and I'm wondering the process for doing so securely.
It depends on how you define a "secure session". There are two issues at play here.
Transport level security: The Firebase JS client communicates with the servers over HTTPS. Additonally, Firebase has a security rules system that lets you specify which clients can read and write which data.
Application level integrity: However, the client is free to make whatever changes it is authorized to, even if they are not triggered by your JS code. For example, in a web page, I can open the developer console and use the Firebase API to make data changes that aren't part of the web page's logic.
To tackle the latter, you'll need a server where you can run trusted code to enforce game state. For instance, every move made by a client in the game should be first put into a "pending" queue. A server process should monitor all pending changes, validate them and them move them to a "final" game state location which will be the authoritative game state.