Firebase Queue Handler Lib

Why use REST API endpoints when you can just use Firebase Queue? That's the premise of this project along with some other requirements for a current piece of software that has lead me to starting this little wrapper for Firebase Queue (NodeJS).


Some of the requirements that lead to this:

  • The server must be self contained, no outside influence except Firebase
  • Need to be able to write in additional server side features fast, like really fast
  • Need something that can clean up after itself


  • Minimize points of failure, everything happens in the realtime database
  • Get all the benefits of Firebase Queue (workers, progress updates, etc)
  • Make it easier to structure your server
  • Be able to write new functionality fast


  • A little bit more database usage (just over 1/3 per request on average)
  • Locked into Firebase Queue, so if there are large breaking updates or incompatibilities you're kind of stuck.

Firebase Queue Handler (FQH) introduces a couple of concepts to the Firebase Queue that you very well could do manually but probably don't want to.

Clean queue definitions

One of the parts I struggled with a little using Firebase Queue on a larger project is that defining queues and managing all of them becomes tedious. I've technically written this wrapper multiple times for various projects, but not with reuse in mind. To define a Firebase queue you do this:

var userQueue = new QHQueue({
	firebaseRef: ref,
	name: 'users',
	handlers: userHandlers,
	responseKey: 'users',
	options: {},
	debug: true

By default the queue doesn't listen for incoming requests. This is so that you can wait for your set up before trying to do a bunch of stuff you don't need to do. Once you are authenticated (or whatever you might need to wait for) simply ask it to listen:


Queue Handlers

When writing up a queue for Firebase, the odds are it could easily handle a few tasks under one specific umbrella. In the readme examples we have one called "users" which handles creating the user data for a new account but I would also put things like profile teardown, friend requests, profile updates, etc. there. A queue can have as many handlers as you wish. You can also write this using a one to one relationship. The choice is yours.

To define handlers, which respond to your specific requests per queue you do this:

var handlers = {
	someAction: function(res) {
		// Do some amazing things here

		return false;
	actionWithResponse: function(res) {
		// Launch spaceships, brew coffee, send a push notification, whatever your heart desires

		var myResponse = {
			foo: "Bar"

		return new QHResponse(myResponse);

On the client side (using the WebSDK) to send a request and get the response, it looks like this:

var requestData = {
	action: 'createUser',
	data: {
		username: 'NorthMcCormick',
		uid: '2gq9VYiWBKS57WPJsv3sahgKs9v1',
		profilePicture: 'data:image/png,TG9sIGknbSBpbXByZXNzZWQgeW91IHRvb2sgdGhlIHRpbWUgdG8gZGVjb2RlIHRoaXM='

var refRequest = ref.child('queue/users/tasks').push();

// Listen on the resolve node for the referral code to show the user!

var referralRef = ref.child('queueResponses/users/' + refRequest.key);
referralRef.on('value', function(snapshot) {
	console.log('We got the referral code: ' + snapshot.val());;

Easy predictable responses

A lot of the time we want to calculate something, send a notification, or pick up data from another endpoint and then get it back to the user. With FQH you can do this right in your handler. Simply return a new QHResponse object with your return data and if the user is listening for it they'll pick it right up. Return false and nothing extra happens.

Write super fast

As you can see, using this is just too easy. Have a new queue you need? Write up one definition, ask it to listen, done. Want to extend your purchases queue to handle a new purchase type? Add a new function to your handler, done.

What's coming?

I've got some big plans for the tool such as:

  • An example project, so be patient please.
  • Being able to have responses automatically expire and self destruct to keep database sizes down
  • Adding more options/configuration
  • Fire app wide events that you can catch in other areas to execute tasks
  • While it is in super-duper alpha and will probably evolve a lot over the next few weeks you should give it a try and see how fast you can get it working.