Single Dashboard, Single Physical Server, Multiple Jobs/Projects/Codebases. Advice or Examples?

question
3

Sorry, i can’t share an example project right now… but i think it won’t be hard to understand:

Basically you’ll be having 3 scenarios:

  • Clients: The applications that enqueue/schedule jobs.
  • Servers: The applications that executes those jobs
  • Dashboard: The place where you see the things that are happening :wink:

The servers must know about the Jobs, as they will be executing it.
The clients must know at least the interface of the Job. (D.I.P.)
The dashborad just need to be connected to the Hangfire database.

All the 3 must be using the same Hangfire database.

If you’ll be following the Dependency Injection Principle for your jobs, and then en queuing/scheduling by the Interface, your Hangfire servers will need to have an IoC container to resolve those dependencies.

As all servers will be using the same Hangfire database, you’ll need to be very restrictive on the “queues” each server execute, 'cos based on the queues they’ll be fetching jobs from the database to execute, and, the server must have the implementation of the job he’s fetching or it could never run.

So, you could have an ISendEmailJobs, marked to run on the email queue:

[Queue("email")]
public interface ISendEmailJobs {
    void EmailType1();
    void EmailType2(string subject);
}

in the application that will do send the emails, the hangfire server must have the queue email :slight_smile:

public static IApplicationBuilder UseHangfire(this IApplicationBuilder app)
{
    app.UseHangfireServer(new BackgroundJobServerOptions()
    {
        Queues = new string[] { "email", "otherqueue" }
    });
}

and, the servers that won’t send email (and, probably won’t have/know those jobs implementation) must not run the email queue.

The Dashboard could run on any of those applications, or in all, or even in another one.
It’s up to you.

Hope that i’ve helped.

1 Like