Alternatives to Hangfire logo

Alternatives to Hangfire

RabbitMQ, NServiceBus, Azure Functions, Sidekiq, and Resque are the most popular alternatives and competitors to Hangfire.
49
39
+ 1
4

What is Hangfire and what are its top alternatives?

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.
Hangfire is a tool in the Background Processing category of a tech stack.
Hangfire is an open source tool with 5.6K GitHub stars and 1.3K GitHub forks. Here’s a link to Hangfire's open source repository on GitHub

Hangfire alternatives & related posts

related RabbitMQ posts

James Cunningham
James Cunningham
Operations Engineer at Sentry · | 18 upvotes · 516.3K views
atSentrySentry
Celery
Celery
RabbitMQ
RabbitMQ
#MessageQueue

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.

#MessageQueue

See more
Tim Abbott
Tim Abbott
Founder at Zulip · | 14 upvotes · 400.8K views
atZulipZulip
RabbitMQ
RabbitMQ
Python
Python
Redis
Redis

We've been using RabbitMQ as Zulip's queuing system since we needed a queuing system. What I like about it is that it scales really well and has good libraries for a wide range of platforms, including our own Python. So aside from getting it running, we've had to put basically 0 effort into making it scale for our needs.

However, there's several things that could be better about it: * It's error messages are absolutely terrible; if ever one of our users ends up getting an error with RabbitMQ (even for simple things like a misconfigured hostname), they always end up needing to get help from the Zulip team, because the errors logs are just inscrutable. As an open source project, we've handled this issue by really carefully scripting the installation to be a failure-proof configuration (in this case, setting the RabbitMQ hostname to 127.0.0.1, so that no user-controlled configuration can break it). But it was a real pain to get there and the process of determining we needed to do that caused a significant amount of pain to folks installing Zulip. * The pika library for Python takes a lot of time to startup a RabbitMQ connection; this means that Zulip server restarts are more disruptive than would be ideal. * It's annoying that you need to run the rabbitmqctl management commands as root.

But overall, I like that it has clean, clear semanstics and high scalability, and haven't been tempted to do the work to migrate to something like Redis (which has its own downsides).

See more
NServiceBus logo

NServiceBus

25
30
0
25
30
+ 1
0
Enterprise-grade scalability and reliability for your workflows and integrations
    Be the first to leave a pro
    NServiceBus logo
    NServiceBus
    VS
    Hangfire logo
    Hangfire

    related Azure Functions posts

    Kestas Barzdaitis
    Kestas Barzdaitis
    Entrepreneur & Engineer · | 15 upvotes · 210.9K views
    atCodeFactorCodeFactor
    Kubernetes
    Kubernetes
    CodeFactor.io
    CodeFactor.io
    Amazon EC2
    Amazon EC2
    Microsoft Azure
    Microsoft Azure
    Google Compute Engine
    Google Compute Engine
    Docker
    Docker
    AWS Lambda
    AWS Lambda
    Azure Functions
    Azure Functions
    Google Cloud Functions
    Google Cloud Functions
    #SAAS
    #IAAS
    #Containerization
    #Autoscale
    #Startup
    #Automation
    #Machinelearning
    #AI
    #Devops

    CodeFactor being a #SAAS product, our goal was to run on a cloud-native infrastructure since day one. We wanted to stay product focused, rather than having to work on the infrastructure that supports the application. We needed a cloud-hosting provider that would be reliable, economical and most efficient for our product.

    CodeFactor.io aims to provide an automated and frictionless code review service for software developers. That requires agility, instant provisioning, autoscaling, security, availability and compliance management features. We looked at the top three #IAAS providers that take up the majority of market share: Amazon's Amazon EC2 , Microsoft's Microsoft Azure, and Google Compute Engine.

    AWS has been available since 2006 and has developed the most extensive services ant tools variety at a massive scale. Azure and GCP are about half the AWS age, but also satisfied our technical requirements.

    It is worth noting that even though all three providers support Docker containerization services, GCP has the most robust offering due to their investments in Kubernetes. Also, if you are a Microsoft shop, and develop in .NET - Visual Studio Azure shines at integration there and all your existing .NET code works seamlessly on Azure. All three providers have serverless computing offerings (AWS Lambda, Azure Functions, and Google Cloud Functions). Additionally, all three providers have machine learning tools, but GCP appears to be the most developer-friendly, intuitive and complete when it comes to #Machinelearning and #AI.

    The prices between providers are competitive across the board. For our requirements, AWS would have been the most expensive, GCP the least expensive and Azure was in the middle. Plus, if you #Autoscale frequently with large deltas, note that Azure and GCP have per minute billing, where AWS bills you per hour. We also applied for the #Startup programs with all three providers, and this is where Azure shined. While AWS and GCP for startups would have covered us for about one year of infrastructure costs, Azure Sponsorship would cover about two years of CodeFactor's hosting costs. Moreover, Azure Team was terrific - I felt that they wanted to work with us where for AWS and GCP we were just another startup.

    In summary, we were leaning towards GCP. GCP's advantages in containerization, automation toolset, #Devops mindset, and pricing were the driving factors there. Nevertheless, we could not say no to Azure's financial incentives and a strong sense of partnership and support throughout the process.

    Bottom line is, IAAS offerings with AWS, Azure, and GCP are evolving fast. At CodeFactor, we aim to be platform agnostic where it is practical and retain the flexibility to cherry-pick the best products across providers.

    See more
    Michal Nowak
    Michal Nowak
    Co-founder at Evojam · | 7 upvotes · 319.9K views
    atEvojamEvojam
    Serverless
    Serverless
    AWS Lambda
    AWS Lambda
    Firebase
    Firebase
    Azure Functions
    Azure Functions

    In a couple of recent projects we had an opportunity to try out the new Serverless approach to building web applications. It wasn't necessarily a question if we should use any particular vendor but rather "if" we can consider serverless a viable option for building apps. Obviously our goal was also to get a feel for this technology and gain some hands-on experience.

    We did consider AWS Lambda, Firebase from Google as well as Azure Functions. Eventually we went with AWS Lambdas.

    PROS
    • No servers to manage (obviously!)
    • Limited fixed costs – you pay only for used time
    • Automated scaling and balancing
    • Automatic failover (or, at this level of abstraction, no failover problem at all)
    • Security easier to provide and audit
    • Low overhead at the start (with the certain level of knowledge)
    • Short time to market
    • Easy handover - deployment coupled with code
    • Perfect choice for lean startups with fast-paced iterations
    • Augmentation for the classic cloud, server(full) approach
    CONS
    • Not much know-how and best practices available about structuring the code and projects on the market
    • Not suitable for complex business logic due to the risk of producing highly coupled code
    • Cost difficult to estimate (helpful tools: serverlesscalc.com)
    • Difficulty in migration to other platforms (Vendor lock⚠️)
    • Little engineers with experience in serverless on the job market
    • Steep learning curve for engineers without any cloud experience

    More details are on our blog: https://evojam.com/blog/2018/12/5/should-you-go-serverless-meet-the-benefits-and-flaws-of-new-wave-of-cloud-solutions I hope it helps 🙌 & I'm curious of your experiences.

    See more

    related Sidekiq posts

    Simon Bettison
    Simon Bettison
    Managing Director at Bettison.org Limited · | 7 upvotes · 212.2K views
    atBettison.org LimitedBettison.org Limited
    PostgreSQL
    PostgreSQL
    Elasticsearch
    Elasticsearch
    Sidekiq
    Sidekiq
    Redis
    Redis
    Amazon ElastiCache
    Amazon ElastiCache
    Rails
    Rails
    RSpec
    RSpec
    Selenium
    Selenium
    Travis CI
    Travis CI
    Ruby
    Ruby
    Unicorn
    Unicorn
    nginx
    nginx
    Amazon CloudFront
    Amazon CloudFront
    Amazon SES
    Amazon SES
    Amazon SQS
    Amazon SQS
    Amazon Route 53
    Amazon Route 53
    Amazon VPC
    Amazon VPC
    Docker
    Docker
    Amazon EC2 Container Service
    Amazon EC2 Container Service

    In 2010 we made the very difficult decision to entirely re-engineer our existing monolithic LAMP application from the ground up in order to address some growing concerns about it's long term viability as a platform.

    Full application re-write is almost always never the answer, because of the risks involved. However the situation warranted drastic action as it was clear that the existing product was going to face severe scaling issues. We felt it better address these sooner rather than later and also take the opportunity to improve the international architecture and also to refactor the database in. order that it better matched the changes in core functionality.

    PostgreSQL was chosen for its reputation as being solid ACID compliant database backend, it was available as an offering AWS RDS service which reduced the management overhead of us having to configure it ourselves. In order to reduce read load on the primary database we implemented an Elasticsearch layer for fast and scalable search operations. Synchronisation of these indexes was to be achieved through the use of Sidekiq's Redis based background workers on Amazon ElastiCache. Again the AWS solution here looked to be an easy way to keep our involvement in managing this part of the platform at a minimum. Allowing us to focus on our core business.

    Rails ls was chosen for its ability to quickly get core functionality up and running, its MVC architecture and also its focus on Test Driven Development using RSpec and Selenium with Travis CI providing continual integration. We also liked Ruby for its terse, clean and elegant syntax. Though YMMV on that one!

    Unicorn was chosen for its continual deployment and reputation as a reliable application server, nginx for its reputation as a fast and stable reverse-proxy. We also took advantage of the Amazon CloudFront CDN here to further improve performance by caching static assets globally.

    We tried to strike a balance between having control over management and configuration of our core application with the convenience of being able to leverage AWS hosted services for ancillary functions (Amazon SES , Amazon SQS Amazon Route 53 all hosted securely inside Amazon VPC of course!).

    Whilst there is some compromise here with potential vendor lock in, the tasks being performed by these ancillary services are no particularly specialised which should mitigate this risk. Furthermore we have already containerised the stack in our development using Docker environment, and looking to how best to bring this into production - potentially using Amazon EC2 Container Service

    See more
    Cyril Duchon-Doris
    Cyril Duchon-Doris
    CTO at My Job Glasses · | 5 upvotes · 44.9K views
    atMy Job GlassesMy Job Glasses
    Redis
    Redis
    Rails
    Rails
    Sidekiq
    Sidekiq
    Amazon SQS
    Amazon SQS

    We migrated from Amazon SQS + Shoryuken to Sidekiq in order to have at-most-once delivery out of the box and more flexibility.

    The UI builtin Rails makes it smoother for development and QA. Through the sidekiq rails engine we can easily see & understand which job is/was/will be executed, and even get some stats for free. Compared to SQS, we lose in scalability (need to manage the underlying Redis instance) but this is not so critical right now for our business size and the PROs clearly outweigh the CONs. Plugins allow to easily add distributed CRON scheduled jobs in there for almost free, and this is a core feature for us, so we no longer need to maintain a "scheduler" instance and we make our CRON jobs more resilient. The Sidekiq UI can easily be tweaked and for instance we have added a column that translates the CRON syntax into a human readable string, so it's easy for our Q/A to check whether the job is scheduled appropriately.

    We still use Amazon SQS for some other apps, but no longer for our main Rails app.

    See more
    Resque logo

    Resque

    95
    65
    8
    95
    65
    + 1
    8
    A Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later
    Resque logo
    Resque
    VS
    Hangfire logo
    Hangfire

    related Beanstalkd posts

    Frédéric MARAND
    Frédéric MARAND
    Core Developer at OSInet · | 2 upvotes · 127.8K views
    atOSInetOSInet
    Beanstalkd
    Beanstalkd
    RabbitMQ
    RabbitMQ
    Kafka
    Kafka

    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.

    See more
    PHP-FPM logo

    PHP-FPM

    47
    36
    0
    47
    36
    + 1
    0
    An alternative FastCGI daemon for PHP
      Be the first to leave a pro
      PHP-FPM logo
      PHP-FPM
      VS
      Hangfire logo
      Hangfire
      delayed_job logo

      delayed_job

      41
      42
      6
      41
      42
      + 1
      6
      Database backed asynchronous priority queue -- Extracted from Shopify
      delayed_job logo
      delayed_job
      VS
      Hangfire logo
      Hangfire

      related delayed_job posts

      Jerome Dalbert
      Jerome Dalbert
      Senior Backend Engineer at StackShare · | 4 upvotes · 57.4K views
      atGratify CommerceGratify Commerce
      delayed_job
      delayed_job
      Rails
      Rails
      AWS Elastic Beanstalk
      AWS Elastic Beanstalk
      Sidekiq
      Sidekiq
      Ruby
      Ruby
      Amazon SQS
      Amazon SQS
      #BackgroundProcessing

      delayed_job is a great Rails background job library for new projects, as it only uses what you already have: a relational database. We happily used it during the company’s first two years.

      But it started to falter as our web and database transactions significantly grew. Our app interacted with users via SMS texts sent inside background jobs. Because the delayed_job daemon ran every couple seconds, this meant that users often waited several long seconds before getting text replies, which was not acceptable. Moreover, job processing was done inside AWS Elastic Beanstalk web instances, which were already under stress and not meant to handle jobs.

      We needed a fast background job system that could process jobs in near real-time and integrate well with AWS. Sidekiq is a fast and popular Ruby background job library, but it does not leverage the Elastic Beanstalk worker architecture, and you have to maintain a Redis instance.

      We ended up choosing active-elastic-job, which seamlessly integrates with worker instances and Amazon SQS. SQS is a fast queue and you don’t need to worry about infrastructure or scaling, as AWS handles it for you.

      We noticed significant performance gains immediately after making the switch.

      #BackgroundProcessing

      See more
      Jerome Dalbert
      Jerome Dalbert
      Senior Backend Engineer at StackShare · | 3 upvotes · 36.9K views
      atStackShareStackShare
      Sidekiq
      Sidekiq
      Ruby
      Ruby
      delayed_job
      delayed_job
      Redis
      Redis

      We use Sidekiq to process millions of Ruby background jobs a day under normal loads. We sometimes process more than that when running one-off backfill tasks.

      With so many jobs, it wouldn't really make sense to use delayed_job, as it would put our main database under unnecessary load, which would make it a bottleneck with most DB queries serving jobs and not end users. I suppose you could create a separate DB just for jobs, but that can be a hassle. Sidekiq uses a separate Redis instance so you don't have this problem. And it is very performant!

      I also like that its free version comes "batteries included" with:

      • A web monitoring UI that provides some nice stats.
      • An API that can come in handy for one-off tasks, like changing the queue of certain already enqueued jobs.

      Sidekiq is a pleasure to use. All our engineers love it!

      See more