Add BullMQ + Redis and prototype notifications queue

[humphd]

This is an initial attempt to add BullMQ and Redis (i.e., ioredis) to our code.

I've done the most basic thing possible vs. making this so it will scale. At the moment we have:

• app/queues/* which holds all of our queues.
• app/queues/notifications.server.ts which is our first queue, dealing with sending user notifications asynchronously. We'll add more as we go, but this can provide a template.
• The Queue and Worker are both co-located in the same file, and in the same process. Down the road, we can break the worker into its own process or container(s). But I didn't want to do this at first, since it will complicate things significantly.

The way this queue would be used is like this. Imagine we want to send a message to a user. The code would be:

import notificationsQueue from '~/queues/notifications.server';

...

// Send a new user a welcome message. Create a unique job id for this job
const jobId = `${user.email}-welcome`;
// Add the job to the queue, passing the data it will need. We have to wait for
// the job to get put into Redis, but not for the email to be sent.
await notificationsQueue.add(jobId, {
  emailAddress: user.email,
  subject: "Welcome to my.custom.domain!",
  message: "We're thrilled to welcome you to my.custom.domain...",
});

The job can now be handled by the Worker, which will attempt to send it at some point in the near future. If it fails, it will retry the job 3 more times, waiting progressively longer each time. We can configure all of this.

I don't have anywhere in the code to hook into this yet, so it's not easy to test.

[ghost]

PR is still in draft, but it looks great!

[humphd]

I added graceful shutdown for the workers and redis.

This won't build yet, I need to get the nodemailer stuff landed first, and then I'll iterate on this some more.

Thanks for the first review @dadolhay, appreciated!

[humphd]

I've updated this to use the work TD just landed for notifications. I also added a /dev page we can use to create test UI and added a button to send a notification.

Once you click the button, it adds a job to the notifications queue. This will get picked up by the worker and an email sent. You can check it in MailHog via http://localhost:8025:

To make this work, I also had to fix our CSP policy in helmetjs. It breaks hot-reloads in the UI due to unsafe inline script injection. We don't want that in production, but in development it's nice so the app responds to code changes in real-time.

What I'm doing here on the /dev page could be copied by other people, who need to try out UI-triggered actions (e.g., @Genne23v with DNS, @dadolhay with Certs).

[humphd]

Added a fix for the node EventEmitter max listeners warning you get when using Redis/BullMQ:

(node:35293) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 17 error listeners added to [Commander]. Use emitter.setMaxListeners() to increase limit

By default, node.js warns if an event emitter has more than 10 listeners; however, the way Redis works, you need way more than that all the time. The recommended fix for this by the BullMQ maintainer is to bump the default value up. In Telescope, we've used 32 as our default and not had any issues.

[SerpentBytes]

Seems to work on my end.