Providers

GrydJobs is designed to be provider-agnostic. The IJobScheduler abstraction allows swapping the underlying job processing engine without changing application code.

Hangfire (Default)

Hangfire is the default and recommended provider for GrydJobs.

Storage

GrydJobs uses PostgreSQL for Hangfire storage via Hangfire.PostgreSql:

builder.Services.AddGrydJobs(options =>
{
    options.ConnectionString = "Host=localhost;Database=gryd_jobs;...";
});

Hangfire will create its own schema (hangfire) in the specified database.

Serialization

GrydJobs configures Hangfire with:

• UseSimpleAssemblyNameTypeSerializer — shorter type names
• UseRecommendedSerializerSettings — optimized JSON serialization

Job Activation

GrydJobs provides a custom HangfireJobActivator that:

1. Creates a DI scope per job execution
2. Restores tenant context via TenantContextAccessor
3. Resolves job instances from the service provider

Job Execution

Four adapter types handle the bridge between Hangfire and GrydJobs:

Adapter	Purpose
JobExecutionAdapter<TJob, TArgs>	Strongly-typed fire-and-forget/delayed jobs
RecurringJobExecutionAdapter<TJob>	Strongly-typed recurring jobs
DynamicJobExecutionAdapter	Runtime type-resolved jobs (from API)
DynamicRecurringJobExecutionAdapter	Runtime type-resolved recurring jobs

Each adapter:

• Resolves the job from DI
• Creates a JobExecutionContext
• Runs the IJobFilter pipeline (OnBefore → Execute → OnAfter/OnError)
• Records metrics and traces via observability providers

Quartz.NET (Future)

A Quartz.NET provider is planned for scenarios requiring:

• Clustered scheduling across multiple nodes
• Calendar-based exclusions
• Job data map persistence

The IJobScheduler abstraction ensures zero code changes when switching providers.

Custom Provider

To implement a custom provider:

1. Implement IJobScheduler
2. Implement IJobMonitor
3. Register in DI:

services.AddScoped<IJobScheduler, MyCustomJobScheduler>();
services.AddSingleton<IJobMonitor, MyCustomJobMonitor>();