EPIC: Dashboard / API Capabilities

[linkdotnet]

This is more of an epic and has to be stripped down to some working packages.
Once we are going in the direction of #25 (state-management) it might make sense to offer a dashboard that allows some more monitoring capabilities.

Initially, that can be read-only, but we might want to allow adding instant jobs via the dashboard (that triggers an API endpoint we have to build anyway).

I am leaning towards an extension package rather than pushing more and more features into the core library itself.

[falvarez1]

Yes!

This feature is indeed an epic and should be approached in modular packages. I propose two potential strategies:

1. Embedded UI for Monitoring:
   Introduce an extension that enables developers to add a UI dashboard for monitoring all the jobs within their application. This would be similar to what Hangfire does. Developers can easily integrate this by adding the optional middleware app.UseJobsUI(); to their application pipeline:

using LinkDotNet.NCronJob;

var builder = WebApplication.CreateBuilder(args);

// Add NCronJob to the service container.
builder.Services.AddNCronJob(n => n
    .AddJob<PrintHelloWorldJob>(p =>
        p.WithCronExpression("*/2 * * * *"))
);

var app = builder.Build();

// Integrate NCronJob UI middleware.
app.UseJobsDashboard();
...
app.Run();

2. Centralized Jobs Control Center:
   Develop a separate, centralized control center/hub that aggregates events/streams from all nodes running jobs. This control center would provide a dedicated dashboard for comprehensive monitoring and control. Nodes would communicate with the control center via a configuration setup in IConfiguration. Here’s a preliminary implementation idea from the client/node perspective:

using LinkDotNet.NCronJob;

var builder = WebApplication.CreateBuilder(args);

// Register NCronJob.
builder.Services
    .AddNCronJob(n =>
        n.AddJob<PrintHelloWorldJob>(p =>
            p.WithCronExpression("*/2 * * * *"))
        )
    .TryJoinJobsControlCenter(builder.Configuration);

var app = builder.Build();

app.Run();

The necessary configuration in appsettings.json might look like this:

{
    "Logging": {
        "LogLevel": {
            "Default": "Information",
            "Microsoft.AspNetCore": "Warning"
        }
    },

    "NCronJob": {
        "ControlCenter": {
            "Url": "http://localhost:7177/hub",
            "ApiKey": "1234567890"
        }
    }
}

Obviously the second approach requires more effort, especially in terms of communication strategy and infrastructure. We can implement either option or both options (centralized hub more of a long term goal).

I am leaning towards an extension package rather than pushing more and more features into the core library itself.

Absolutely, we need to start breaking the project into a core and then the separate extension components that rely on core. Keeping the core library lean makes it easier to maintain.

[linkdotnet]

I do like the second approach as it gives a USP for this library.
Let's keep that open and tackle it once we have a definitive idea on how to tackle it and how to tackle #25