Hacker News Reader

Comment by drTriumph | Hacker News Reader

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!

View on HN

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

Firebase and AWS user. Is this similar to AWS SQS. Any performance or other benefits?

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

Is this using the streaming API or polling?

It uses the Node Firebase client: https://www.npmjs.com/package/firebase

Reply on news.ycombinator.com