

Introducing Firebase Queue - rickharrison
https://www.firebase.com/blog/2015-05-15-introducing-firebase-queue.html

======
drTriumph
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!

~~~
primitivesuave
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.

~~~
drTriumph
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.

------
ibejoeb
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?

~~~
timdumol
It's worth noting that exactly-once delivery is impossible:
[http://bravenewgeek.com/you-cannot-have-exactly-once-
deliver...](http://bravenewgeek.com/you-cannot-have-exactly-once-delivery/)

------
sync
So 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?

