Hi 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/<user-id>. 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.
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.
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
Firebase and AWS user. Is this similar to AWS SQS. Any performance or other benefits?
How does this compare to the reliability of RabbitMQ on the server side?
Can you have multiple simultaneous queues? And multiple listeners per queue?
What is latency and performance like, especially with third-party server workers?
I 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.