Alternative To Quartz .NET

Introduction

Quartz .NET is one of the most popular scheduling and background job libraries in dotnet. Originally, Quartz existed exclusively as a Java-only implementation, but a developer later came along and ported Quartz to the dotnet community. The author has a dedicated site and GitHub repository for Quartz .NET that you can take a look at today.

In this article, we explore the differences between Didact and the Quartz .NET library and show why Didact might be the alternative solution that you and your team are looking for.

Application vs Library

The most striking difference between Didact and Quartz .NET is that Didact is a fully-featured, prebuilt application ready for usage as is while Quartz .NET is a library that you need to integrate into your application.

This characteristic alone can be a major determining factor for you and your team when you are trying to decide which technology to use, so consider your use case and motivations carefully.

I have intentionally created Didact as a prebuilt application - rather than a library - for a variety of reasons, some of which I explain below.

Dedicated Application

In every instance that I have required job orchestration - background jobs, scheduled jobs, CRON jobs, asynchronous jobs, or "out of process" jobs - I have always setup a dedicated application separate from my main web application. While it is true that, within a certain scale and tolerance, you can get away with adding a background library to your main web application, I think it is both unnecessary and architecturally unwise for your dev team to do so, and here is why:

Competing Responsibilities

Eventually, you will likely get to a level of automation or scale where your application is consuming too much compute resources dealing with job orchestration and background work. This will inevitably clash with the primary functions of your web application, such as serving requests, rendering HTML pages, and so on.

For example, if you need to execute CPU intensive work for complex calculations, your main web application could very likely suffer from threadpool starvation as user requests pile up. This, of course, translates to loading spinners, slow page loads, and overall an unenjoyable user experience in your main web application.

Simple Infrastructure Setup

Whether your infrastructure is on-premise Windows servers, Azure App Services, or a $5 VPS on Digital Ocean, the fact is it is very simple to setup a new web application. Adding a new app to your IIS instance or spooling up a new Azure App Service is a minimal amount of DevOps work, and when your job orchestrator eventually scales with higher levels of automation or job throughput, you are not going to want to shift around architecture that is tighly-coupled to your main, user-facing web application. In this instance, you will be very thankful that you already have a conveniently-separated, dedicated application for dotnet background jobs.

Skipping the Boilerplate and Ceremony

The downside to having a dedicated application for dotnet job orchestration and dotnet background jobs is that setting up a brand new application typically involves a certain amount of boilerplate code, configurations, and other such begrudging "ceremonies" for developers to endure.

You can certainly go through these begrudging ceremonies and boilerplate with background job libraries like Quartz .NET if you want to, but in my opinion, it is infinitely more convenient to have a templated, pre-made, and highly optimized application prepared for you as is that functions in a plug-and-play fashion.

This is exactly what my vision for Didact is.

No Web Dashboard

One of the major downsides to Quartz .NET is that, unlike Hangfire and Didact, it does not ship with an official, author-supported web dashboard. I have learned over the years that everyone appreciates a beautiful and useful user interface, even developers who spend most of their time looking at code.

Like Hangfire and Didact, Quartz .NET stores job metadata in a persistent storage medium of your choice - such as a SQL Server database instance - but it is entirely up to you and your team to design and maintain a web dashboard to run on top of it. Designing a web dashboard from scratch will cost you time, money, and developer resources that you could be spending on other, important company projects instead. And moreoever, you would then need to maintain your web dashboard after its initial design and ensure that it remains constantly compatible with future versions of Quartz .NET.

In my opinion, that is a costly endeavor that you should not bother your dev team with. Instead, it would be much more advantageous for you to use a solution with a web dashboard shipped "out of the box". This is one of the primary advantages of Didact, as it ships with a VueJS-powered web dashboard, aptly named Didact UI.

There were, at least previously, some open source, unofficial web dashboards for Quartz .NET, but many - if not all - have since been abandoned by the authors. This leads us into an interesting subconversation about open source that I explore below.

No Dedicated Support

If you run or are a part of a business, this part is especially important for you to think long and hard about!

Free Open Source Software

Quartz .NET is a free open source (FOSS) software product, and I want to commend the author and Quartz .NET's community of contributors for building a powerful - and obviously popular - background job solution for dotnet, especially considering that it is permissively-licensed and free of charge even for commercial use.

That is one of the greatest strengths and utter beauties of FOSS technology, and we should always be quick to express our appreciation for such authors and such software products.

Business Critical

That being said, however, I want you to think about what a proper dotnet job orchestrator or background job library does. Think about your use case, think about your hundreds (thousands? millions? billions?) of automations and background jobs that you want to run. These are very likely extremely critical, high throughput pieces of infrastructure that form part of your business's lifeblood.

And for such an integral piece of business infrastructure, your business needs assurity of two things:

• The job orchestrator will run excellently and without issues.
• If there are issues, you need be darn well sure that you can get support and fix those issues as soon as possible.

With Quartz .NET, there are no such options for dedicated or paid support, as discussed here on GitHub. If something critical breaks, or if you want dedicated support straight from the founder themselves, you are unfortunately out of luck. This is the double-edged sword that comes with FOSS; after all, we can't expect or demand someone to tirelessly give us free labor with no compensation in return.

Commercial Open Source Software

Contrarily, Didact is a commercial open source (COSS) software product. This is something that I have been upfront with early adopters and users about from day one, and rightfully so.

I understand how critical, how essential it is for a job orchestrator to run smoothly and without issue. And when issues inevitably arise - and in software, something always bubbles up eventually - I know that you and your business will want the assurance and comfort that you can talk to someone on the other end of the line.

Additionally, if you are going to adopt Didact, you will want some sort of guarantee that it's going to stick around for the long term. After all, what do you do if I were to provide you Didact as a FOSS product, but I burn out a few months from now, completely drop support, and otherwise abandon the project? "Ouch" is what you and your dev team would be saying while you refactor a major part of your software infrastructure.

By charging you for things like enhanced features and dedicated support, I help us engage in a business transaction that is mutually beneficial:

• You and your business can get dedicated support if something breaks. Even better, since I'm a solopreneur, you get support directly from the author of Didact himself!
• I can get my bills paid with your subscription which means I won't burn out or disappear into the void months from now.
• By running a profitable and customer-funded business, I can keep investors out of the picture and make everything in Didact about serving my customers rather than trying to reach a massive startup IPO years from now.
• I can continue investing in the Didact platform, fixing bugs and adding powerful new features, and making it the best job orchestrator your business will ever desire.

For something like a job orchestrator, I think this is a valid case for COSS rather than FOSS.

Class Library Project

Architecturally, another major difference between Didact and Quartz .NET is that your jobs - which are called Flows in Didact - are defined in a separate, dedicated dotnet class library project. As is the nature of a dotnet class library project, its build artifacts are .dll files rather than an executable.

"What good do .dll files do for me?" you may ask. An excellent question, one that you can see more details about on Didact's architecture page, but in essence Didact Engine dynamically, after startup, and at runtime "absorbs" your class library project from a library source that you define.

When this absorbtion happens, your class library project - which, as a reminder, contains all of your Flows - is automatically and seamlessly integrated with Didact Engine's already-running execution context. Your Flow's metadata configurations are persisted to the database, localized dependency injection is initiailized, and Didact Engine begins enqueueing and executing your Flows.

Plug and Play

Again, I would strongly encouraging you to review the architecture page and further read about the engine mechanics on Didact's docsite, but in summary, this creates a beautiful, always-running, and completely-dynamic execution platform for your jobs to be done. One of the keywords I want Didact user's to resonate with is the idea that Didact is a plug-and-play platform.

Your primary responsibility in Didact is to define your Flows and their dependencies. That and setting up Didact Engine and Didact UI is all that I want you to worry about.

Always Running

I want to draw special attention to a phrase that I used above: always running.

This is perhaps one of the greatest architectural side effects of all for Didact vs a background job library solution like Quartz .NET: Didact is an always-running execution platform. It is specifically and intentionally built for uninterrupted class library absorbtions, where you simply set Didact up to run on a server, for example, and add, delete, or edit jobs at will without requiring engine shutdowns.

No solution outside of Didact in the entire dotnet ecosystem provides this tremendous convenience for you.

Separation of Concerns

A nice side effect of having a centralized class library project for your Flows is that it forces you to utilize a separation of concerns. Your jobs are easily found in a centralized location rather than being littered throughout the rest of your production codebase or within a large web application's source code. Organization, refactoring, and teaching new developers about your background jobs becomes orders of magnitude more easy and naturally occurring.

Event System

As I have contemplated the metadata data model of Didact, I have settled on the idea that a detailed event model would be highly beneficial for Didact's users. And when I say highly detailed, I really mean highly detailed.

I think an event history for a job orchestrator should contain a variety of detailed information, such as:

• When a job is enqueued.
• When a job status changes, from what value to what value and why the change occurred.
• The detailed internal job lifecycle events, even from the deeper parts of the execution engine.
• A connected set of executions including retries to comprehensively tell the job's entire story.
• Custom logging events.
• Engine misfires.
• And more.

Neither Quartz .NET nor any other dotnet solution has a metadata data model this comprehensive, but this is something I want to offer you as a strong incentive to use Didact.

Ideally, things don't go wrong, your Flows run flawlessly, all is good in the universe. But on the off chance something does happen, I want a plethora of metadata automatically collected for you and at your disposal for detailed investigations and post-mortems.

Summary

All in all, I hope you found some of my reasoning and argumentation here compelling for why you and your company might want something more than just a dotnet background job library. I strongly believe that you - and the dotnet community as a whole - will benefit massively from finally having a true, proper dotnet job orchestrator at your disposal.

A tool like this will really bring us up to modern standards for fields like asynchronous execution and data engineering, and I believe it will empower your business to automate and scale background work in ways you may have previously thought impossible to achieve.

If you have any further questions, don't hesitate to reach out to me.