It is my experience of anti-pattern of HangFire implementation.
We have multiple applications that needs HangFire feature. The idea was to be scalable and centralized at the same time. We figured out that it’s possible to install a HangFire as a separate windows service having its own database. We set up Hangfire Dashborad as a separate web site. Each business application call HangFire’s fire and forget function, which saved as a queue to HangFire database. Once the queue is saved, the separate HangFire retrieved the queue and processed it.
In a sense that, it was a separation of concern. It was a similar structure like any other message queue system.
However, the problem was that the HangFire process should be able to call the function in the queue. The function is business logic of the caller application. To be able to process the function, we need the business logic to be referenced by HangFire instance. The business logic was managed by a shared library between the business application and HangFire instance. Each time business logic changes, the change needs to be made in the shared library and deployed to both business application and Hangfire instance.
The issue was the shard library is hard to manage when it’s shared by multiple applications as we need to make sure the change works in all client applications and make sure the changed code deployed to all client applications including HangFire instance. Another burden was that we need to manage the separate HangFire instance, HangFire Dashboard and HangFire database. If hosted in cloud, this is an extra cost as well.
I decided to solve this problem by installing HangFire to each business application and removed separate HangFire instance. At first glance, it looks like a duplicate. But, I keep realizing that ‘duplicate’ can be beneficial in some cases. (It apply to coding and database field as well)
There are many benefits of having HangFire inside the business application. 1. No need to worry about managing shared business logic between biz application and HangFire instance. Once you made a change to function in the business application, that’s it. There is no more to concern. 2. Each business application may need a different configuration on HangFire. For example, one business application requires sequential processing of queue without multi processing. It’s easier to apply this options when HangFire is separate to each business app. 3. Reduction of extra cost to host the independent HangFire instance.
Since this change, I’m happy how the system works.