Hangfire vs RabbitMQ: What are the differences?
What is Hangfire? Perform background processing in .NET and .NET Core applications. It is an open-source framework that helps you to create, process and manage your background jobs, i.e. operations you don't want to put in your request processing pipeline. It supports all kind of background tasks – short-running and long-running, CPU intensive and I/O intensive, one shot and recurrent.
What is RabbitMQ? A messaging broker - an intermediary for messaging. RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.
Hangfire belongs to "Background Processing" category of the tech stack, while RabbitMQ can be primarily classified under "Message Queue".
Hangfire and RabbitMQ are both open source tools. RabbitMQ with 6.07K GitHub stars and 1.85K forks on GitHub appears to be more popular than Hangfire with 4.93K GitHub stars and 1.12K GitHub forks.
reddit, 9GAG, and MIT are some of the popular companies that use RabbitMQ, whereas Hangfire is used by Gbase, TrackJS, and PagueVeloz. RabbitMQ has a broader approval, being mentioned in 1224 company stacks & 2897 developers stacks; compared to Hangfire, which is listed in 9 company stacks and 9 developer stacks.
What is Hangfire?
What is RabbitMQ?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose Hangfire?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Hangfire?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Hangfire?
Sign up to get full access to all the tool integrationsMake informed product decisions
As Sentry runs throughout the day, there are about 50 different offline tasks that we execute—anything from “process this event, pretty please” to “send all of these cool people some emails.” There are some that we execute once a day and some that execute thousands per second.
Managing this variety requires a reliably high-throughput message-passing technology. We use Celery's RabbitMQ implementation, and we stumbled upon a great feature called Federation that allows us to partition our task queue across any number of RabbitMQ servers and gives us the confidence that, if any single server gets backlogged, others will pitch in and distribute some of the backlogged tasks to their consumers.
Beamery runs a #microservices architecture in the backend on top of Google Cloud with Kubernetes There are a 100+ different microservice split between Node.js and Go . Data flows between the microservices over REST and gRPC and passes through Kafka RabbitMQ as a message bus. Beamery stores data in MongoDB with near-realtime replication to Elasticsearch . In addition, Beamery uses Redis for various memory-optimized tasks.
The question for which Message Queue to use mentioned "availability, distributed, scalability, and monitoring". I don't think that this excludes many options already. I does not sound like you would take advantage of Kafka's strengths (replayability, based on an even sourcing architecture). You could pick one of the AMQP options.
I would recommend the RabbitMQ message broker, which not only implements the AMQP standard 0.9.1 (it can support 1.x or other protocols as well) but has also several very useful extensions built in. It ticks the boxes you mentioned and on top you will get a very flexible system, that allows you to build the architecture, pick the options and trade-offs that suite your case best.
For more information about RabbitMQ, please have a look at the linked markdown I assembled. The second half explains many configuration options. It also contains links to managed hosting and to libraries (though it is missing Python's - which should be Puka, I assume).
I used Kafka originally because it was mandated as part of the top-level IT requirements at a Fortune 500 client. What I found was that it was orders of magnitude more complex ...and powerful than my daily Beanstalkd , and far more flexible, resilient, and manageable than RabbitMQ.
So for any case where utmost flexibility and resilience are part of the deal, I would use Kafka again. But due to the complexities involved, for any time where this level of scalability is not required, I would probably just use Beanstalkd for its simplicity.
I tend to find RabbitMQ to be in an uncomfortable middle place between these two extremities.
I developed one of the largest queue based medical results delivery systems in the world, 18,000+ queues and still growing over a decade later all using MQSeries, later called Websphere MQ. When I left that company I started using RabbitMQ after doing some research on free offerings.. it works brilliantly and is incredibly flexible from small scale single instance use to large scale multi-server - multi-site architectures.
If you can think in queues then RabbitMQ should be a viable solution for integrating disparate systems.
The poster child for scalable messaging systems, RabbitMQ has been used in countless large scale systems as the messaging backbone of any large cluster, and has proven itself time and again in many production settings.
Rabbit acts as our coordinator for all actions that happen during game time. All worker containers connect to rabbit in order to receive game events and emit their own events when applicable.
Used as central Message Broker; off-loading tasks to be executed asynchronous, used as communication tool between different microservices, used as tool to handle peaks in incoming data, etc.
RabbitMQ is the enterprise message bus for our platform, providing infrastructure for managing our ETL queues, real-time event notifications for applications, and audit logging.