Hosting Extensions

The CritterWatch.Services package exposes two extension methods for ASP.NET Core applications.

AddCritterWatch()

Registers all CritterWatch dependencies into the ASP.NET Core IServiceCollection / IHostApplicationBuilder:

builder.AddCritterWatch(
    postgresConnectionString: "Host=localhost;Database=critterwatch;Username=postgres;Password=postgres",
    configureWolverine: opts =>
    {
        opts.UseRabbitMq(new Uri("amqp://localhost")).AutoProvision();
        opts.ListenToRabbitQueue("critterwatch").Sequential();
    });

What it registers

• Wolverine — handlers for incoming telemetry and outgoing operator commands; routing for the configured transport.
• Marten — the console's own PostgreSQL schema (critterwatch) for state, history, alerts, and audit log.
• SignalR hub — push channel to the browser, configured with camelCase + string-enum JSON.
• Alert evaluator — runs on a 30-second pass evaluating thresholds against incoming telemetry.
• Background maintenance — retention enforcement, periodic cleanup.
• Health checks — basic Postgres connectivity check.

Overloads

The first argument is either a connection string or a pre-built NpgsqlDataSource; the rest are optional callbacks (configureWolverine, configureHub) plus the cluster-partitioning knobs (enableClusterPartitioning, configureClusterShardedTopology — see Clustering).

// Connection string + Wolverine configuration.
builder.AddCritterWatch(connectionString, configureWolverine);

// Also tune the SignalR HubOptions (third argument).
builder.AddCritterWatch(connectionString, configureWolverine, configureHub);

// Or hand in a pre-built NpgsqlDataSource instead of a connection string —
// e.g. the one Aspire injects into DI.
builder.AddCritterWatch(dataSource, configureWolverine);

UseCritterWatch()

Maps CritterWatch middleware into the ASP.NET Core request pipeline:

app.UseCritterWatch();

// With a custom SignalR route:
app.UseCritterWatch(signalRRoute: "/my-hub");

What It Maps

Wolverine HTTP:

• Maps all HTTP endpoints defined with [WolverineGet], [WolverinePost], etc. in CritterWatch.Services
• These are mounted under /api/critterwatch/*

SignalR Hub:

• Maps the CritterWatch SignalR communication hub at the configured route (default /api/messages) — this is the browser's live push channel.

Static Files (Embedded SPA):

• Configures StaticFileMiddleware to serve embedded Vue SPA resources
• Falls back to index.html for all unmatched routes (client-side routing)

Call Order

UseCritterWatch() should be called after UseRouting() and any authentication/authorization middleware, but before the fallback handler. The typical order is:

app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.UseCritterWatch();
app.Run();

Schema isolation

The console's bookkeeping lives in its own dedicated critterwatch schema. It doesn't collide with — and doesn't read from — any other Marten stores you may configure in the same database.

You can point the console at a database that's already used by another application; it'll create its schema, leave everything else alone, and run side-by-side.

Connection-string security

The PostgreSQL connection string is read from your console's configuration and stays there. It is not transmitted to monitored services or the browser. Use appsettings.json with environment-variable overrides (or your secret manager of choice) for production deployments.