Introducing Firebase Queue
firebase.com
Introducing Firebase Queue
1–10 of 14 posts
Re: Introducing Firebase Queue
#2So what does this do exactly? It's not running the code itself as far as I can tell... so it is merely reporting on the status of the background job?
Re: Introducing Firebase Queue
#3Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
Re: Introducing Firebase Queue
#4I read the readme but I didn't find any info about delivery guarantees. Do we know if tasks are guaranteed to be delivered once and only once, or if there is possible data loss or duplication?
Re: Introducing Firebase Queue
#5I read the readme but I didn't find any info about delivery guarantees. Do we know if tasks are guaranteed to be delivered once and only once, or if there is possible data loss or duplication?
By specifying a timeout on a task spec or not you can specify whether a task is tried at least once or at most once.
Re: Introducing Firebase Queue
#6Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
My solution so far has been to write my own Node server that listens to a particular branch for requests, and use the rules to enforce that a user can only write to /request/. When making a request, a user writes data to their user ID's request branch, and listen for changes made by the server to their request. This has worked out great, but the Java server is now a point-of-failure. It would be great to get some information on how this would be an improvement over my current setup.
Re: Introducing Firebase Queue
#7I read the readme but I didn't find any info about delivery guarantees. Do we know if tasks are guaranteed to be delivered once and only once, or if there is possible data loss or duplication?
It's worth noting that exactly-once delivery is impossible: http://bravenewgeek.com/you-cannot-have-exactly-once-deliver...
Re: Introducing Firebase Queue
#8Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
How does this compare to Parse's Cloud Code?
Re: Introducing Firebase Queue
#9Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
My solution so far has been to write my own Node server that listens to a particular branch for requests, and use the rules to enforce that a user can only write to /request/ . When making a request, a user writes data to their user ID's request branch, and listen for changes made by the server to their request. This has worked out great, but the Java server is now a point-of-failure. It would be great to get some in…
The biggest advantage would be that you can have multiple server processes listening for requests on the same path and know that only one will be processing it at any point in time. That way your process is no longer a single point if failure.
Re: Introducing Firebase Queue
#10Hi HN, I'm the lead engineer on Firebase Queue. I think it will make processing background tasks in Firebase much easier, and we're already using it for some projects internally. I'd love to hear what you think when you try it out!
How does this compare to Parse's Cloud Code?
This is not a hosted solution - you will have to run your own server still with Firebase Queue