Reviewing the docs
https://www.hangfire.io/overview.html
We have a fairly typical web application in a solution that includes a few class library projects, one of which serves as a “data layer” and includes an entity framework DbContext.
Currently, to handle automation, we use powershell to automate the calling of some of the code and we are looking at moving more of this type of activity this way, hence looking at something like Hangfire.
Looking at these two options:
(1) Single process:
Hangfire installed within an existing web app, jobs defined as making calls into methods within assemblies that are referenced by the web app as well.
(2) Separate (windows) service:
Hangfire would be installed into new windows service project, likely within the same solution as the web app mentioned above. Question - what would the code in this service call? Eg. if the code to be executed resides in the class libraries being used by the web app, then you have maybe two choices (a) include the windows service project in the same solution as the web project so you can reference the same class libraries or (b) define web api enpoints that the windows service can call within job(s)
The good thing about a separate service is that you can scale them separately. Also you can deploy them on different server and if one uses a lot of processing power it won’t slow down the other application.
Other option for separate services is creating a Nuget package containing your interfaces, then just importing that Nuget in both solutions so they can communicate. The web app enqueue using the interface method. The worker load the interface from the dependency injection and enqueue the method using the implementation class. That way the web app doesn’t have the code of the work inside of it.
It all depends on your specific environment. Single process is easier to maintain but less flexible and less scalable. Different services are harder to maintain but are more flexible and more scalable
Another option you have is to have Hangfire in a dedicated website that you can scale out as necessary. Doesn’t necessarily have to be stood up in a windows service. It might make more sense to have two websites in the same solution, sharing the “Job Library” code for queuing and processing Jobs. Then you can deploy the Hangfire website with the same strategy as your existing web app, perhaps just to more servers (if necessary).
Otherwise it’s like what @Steven_Desrochers said, your Hangfire architecture comes down to:
- Whether you deem the potential load large enough to justify the overhead and complexity of managing different websites/services/apps to distribute said load
- Which platforms you feel most comfortable deploying and managing: windows service, website, app
1 Like