Kevsoft.AspNetCore.SignalR.MongoDB 1.0.1

Kevsoft.AspNetCore.SignalR.MongoDB

Kevsoft.AspNetCore.SignalR.MongoDB is a MongoDB-backed scale-out provider for ASP.NET Core SignalR. It is being built to support two MongoDB transport modes: change streams for replica sets/sharded clusters, and tailable-await cursors over capped collections for standalone-friendly deployments.

Setup

Register MongoDB scale-out from the SignalR server builder. Use the Use* methods on the options object to configure each concern — they group related properties together so it is clear which settings belong together and prevent mixing incompatible configuration.

Connection string

builder.Services
    .AddSignalR()
    .AddMongoDb(options =>
    {
        options.UseConnectionString(builder.Configuration.GetConnectionString("MongoDB")!, "my_app");
        options.UseChangeStreams();
        options.CollectionName = "signalr_messages";
        options.ChannelPrefix = "my-app";
    });

If the connection string already includes a database name, the single-argument overload infers it:

builder.Services
    .AddSignalR()
    .AddMongoDb("mongodb://localhost:27017/my_app");

Existing IMongoClient

If your application already configures a MongoClient, pass a factory together with the database name:

builder.Services
    .AddSignalR()
    .AddMongoDb(options =>
    {
        options.UseMongoClient(sp => sp.GetRequiredService<IMongoClient>(), "my_app");
    });

Existing IMongoDatabase

If your application registers an IMongoDatabase directly (e.g. via a shared infrastructure registration), call UseMongoDatabase inside any AddMongoDb callback. Connection string and database name are not required when using this path:

builder.Services
    .AddSignalR()
    .AddMongoDb(options =>
    {
        options.UseMongoDatabase(sp => sp.GetRequiredService<IMongoDatabase>());
    });

Tailable-await (standalone MongoDB)

builder.Services
    .AddSignalR()
    .AddMongoDb(options =>
    {
        options.UseConnectionString(builder.Configuration.GetConnectionString("MongoDB")!, "my_app");
        options.UseTailableAwait(o =>
        {
            o.CollectionSizeBytes = 64 * 1024 * 1024;
            o.MaxAwaitTime = TimeSpan.FromSeconds(1);
        });
        options.CollectionName = "signalr_capped_messages";
    });

Resolving configuration from DI inside the callback

All AddMongoDb overloads have an Action<IServiceProvider, MongoDbSignalROptions> variant that gives access to the root service provider. This is useful when the MongoDB settings live in a registered service rather than being available at registration time:

builder.Services
    .AddSignalR()
    .AddMongoDb((sp, options) =>
    {
        var cfg = sp.GetRequiredService<IConfiguration>();
        options.UseConnectionString(cfg.GetConnectionString("MongoDB")!, cfg["SignalR:Database"]!);
        options.ChannelPrefix = cfg["App:Name"];
    });

Note: The IServiceProvider passed to these callbacks is the root (singleton-scope) provider. Do not resolve scoped services from it.

Transport modes

Both modes treat SignalR backplane messages as ephemeral. Cold starts begin from live messages and do not replay historical documents into current hub connections.

Key options

The Use* methods on MongoDbSignalROptions are the only way to configure connection and transport properties (their setters are private). General options use regular property assignment.

Connection methods

Transport methods

MongoDbSignalRChangeStreamOptions

MongoDbSignalRTailableAwaitOptions

General options

Operational notes

• Change streams require MongoDB to run as a replica set or sharded cluster. They are the preferred mode for production clusters.
• Tailable-await requires a capped collection. Size it for the largest outage or burst you need to tolerate: average message bytes * messages per second * tolerated outage seconds, plus headroom for indexes and message-size spikes.
• Checkpoints are not a durable replay mechanism. They are only used to reduce gaps during in-process cursor interruptions.
• MongoDB TTL cleanup is best-effort; documents can remain briefly after MessageTtl. Keep MessageTtl long enough for expected reconnect windows, but short enough to avoid unbounded collection growth.
• The change-stream transport creates TTL and stream/time indexes when index creation is enabled. Connection presence uses stream/connection and TTL indexes.
• MongoDB writes use the driver/database defaults for write concern unless applications configure the supplied MongoClientSettings. Stronger write concern can improve durability at the cost of latency.
• MongoDB inserts cannot report how many SignalR servers are subscribed. The implementation uses separate MongoDB presence records and heartbeats for remote connection checks.
• Unlike Redis pub/sub, MongoDB messages are stored briefly in collections. This helps cursor recovery but means capped-collection sizing, TTL cleanup, and collection permissions are operational concerns.

Contributing

1. Issue
2. Fork
3. Hack!
4. Pull Request