The main purpose of the Queue API is to provide a way for us to add items to a queue in order to have them processed at a later time. In charge of processing these items are the queue worker plugins, which can be enlisted either automatically by the Drupal cron, manually (programmatically) by us, or by Drush. We will look at an example of all three.

The central player in this API is an implementation of the QueueInterface, which is the actual queue into which we put items. There are two types of queues Drupal can handle: reliable and unreliable. The first preserves the order in which the items are processed (first in, first out) and guarantees that each item gets processed at least once. In this chapter, we will focus only on this type of queue. But there is also the possibility of working with unreliable queues which give their best effort when maintaining the item order and do not guarantee that all items get processed.

By default, when we are working with queues in Drupal 8, we use a reliable queue that is based on a database table to store the items. This is represented by the DatabaseQueue implementation. The Batch API in fact uses a type of queue that extends from the default one Drupal comes with. Okay, but what does a queue do?

A queue has three main roles:

• It creates items (adds stuff to a list that needs processing at some point).
• It claims items (puts a hold on them while a worker does the processing).
• It deletes items (removes the items from the queue once they have finished processing). Alternatively, it can also release them if another worker needs to process them or something went wrong and it should be retrieved later on.

We will soon see a practical example of how this works. But first, let's look at how a queue comes about.

The QueueInterface implementation is created with the help of the QueueFactory service, named queue. The factory delegates to another factory service specific to the type of queue being created. By default this is the QueueDatabaseFactory service (named queue.database), which expectedly returns an instance of the DatabaseQueue class. The table used by the latter is simply called queue.

Finally, the crux of the Queue API for us module developers is the system of QueueWorker plugins that are responsible for processing a single item in the queue. These can be written in two ways. The simplest approach is to have them triggered by cron. In this case, the plugin ID needs to match the name of the queue it needs to process items for. This way, we don't have to worry about claiming, releasing, or deleting items. The cron system does it for us. However, a more flexible approach is the one in which we actually do that. We don't rely on cron but process the items ourselves whenever we want. Moreover, both types of queue workers can be enlisted via Drush using a command that triggers the processing of a queue with a given name.