Correct way to set up several purpose workers

[xzilja]

I'm slowly starting to grasp firebase-queue and truly believe it is a great approach to workers! I'm trying to figure out if my approach below is correct way to handle several diiferent data validation tasks for my game.

I've set up firebase admin and several queues like so:

import admin from 'firebase-admin';
import Queue from 'firebase-queue';

// -- initialize firebase --------------------------------------------------- //
admin.initializeApp({/* credentials */});

// -- create firebase queue ------------------------------------------------- //
const queueOptions = {
  numWorkers: 5,
  sanitize: false
};

/* character creation */
const createCharacterRef = admin.database().ref('queue/create');
const createCharacter = new Queue(createCharacterRef, queueOptions, (data, progress, resolve, reject) => {
  // Check if data is valid for character
  // push new character to firebase database at /characters
});

/* item purchase */
const purchaseItemRef = admin.database().ref('queue/purchase');
const purchaseItem = new Queue(purchaseItemRef, queueOptions, (data, progress, resolve, reject) => {
  // Validate purchase request data
  // Check firebase database /characters/uid to have enough gold to purchase item
  // purchase item, place it in character and subtract cost
});

/* and so on */

Is this how you'd structure several queue tasks that need to perform different operations?

[katowulf]

Seems like a solid approach. Note that you can also have your queue items use _state so that workers are only triggered when a queued item reaches a certain point in the process. In this way, you can make your code into an event stream and keep the workers very flexible and minimal.

It might be overkill, or particularly useful, depending on your game logic. For example, conducting an in-game "give item" could be set up like the following:

• Give item is queued at queue/give, the "default" workers pick it up and validates that it's allowed (e.g. enough reputation, friends with the recipient, etc), then sets _state to offer
• The "offer" workers pick up the queued task at this point and notify the recipient that a trade has been offered, then change the _state to pending
• The recipient would then respond by accepting or declining, probably by modifying the queue'd request's state or maybe by submitting a separate request, but ultimately the task's _state would end up at either accept or decline
• Another worker could then add the item to the recipients inventory and remove it from the sender's. The queued task is then marked as completed.

Some neat things about this approach: Each worker is probably five or ten lines of code. Changing the logic of how an item is transferred probably just means changing the states and adding or removing workers from the mix. If the process fails at any point due to bugs or a server crashing, you'll be able to track which state it was in and probably resume the process later without any loss of items.

[xzilja]

@katfang this is great explanation! Thank you.