Nedo.AspNet.Notifications.Abstractions 1.0.0

Nedo.AspNet.Notifications

Store-and-forward notifications for ASP.NET Core: a message is persisted first, fanned out into one delivery row per device, and sent by a background dispatcher that retries with backoff. Nothing is sent inside the request that raised it, so a slow or unreachable transport cannot fail a user's action, and a restart resumes instead of losing the queue.

Install

dotnet add package Nedo.AspNet.Notifications
dotnet add package Nedo.AspNet.Notifications.Firebase   # transport

Wiring

The library never names your DbContext. Implement INotificationStore on the context that owns the three tables and register it:

public class AppDbContext : DbContext, INotificationStore
{
    public DbSet<NotificationMessage> NotificationMessages => Set<NotificationMessage>();
    public DbSet<NotificationDelivery> NotificationDeliveries => Set<NotificationDelivery>();
    public DbSet<UserDeviceToken> UserDeviceTokens => Set<UserDeviceToken>();
}

builder.Services.AddNedoNotifications<AppDbContext>(builder.Configuration);
builder.Services.AddFirebaseNotifications();

AddNedoNotifications reads its own Notifications configuration section — templates, whether the dispatcher runs in this process, batch size and backoff. Migrations are yours: the entities map through your context, so your application generates the DDL that matches your own naming.

Raising one

await dispatcher.QueueAsync(new NotificationRequest
{
    Type   = "invoice.issued",          // stable machine key; your own vocabulary
    UserId = user.Id,
    Title  = "Invoice issued",
    Body   = "Invoice #1042 is ready.",
    Data   = new Dictionary<string, string> { ["invoiceId"] = "1042" },
});

The dispatcher claims rows it is about to send, so several instances can run the queue without two of them sending the same delivery. A token the transport reports as dead is retired rather than retried; a transient failure backs off and is tried again.

Transports

INotificationSender is the seam. The Firebase package implements it over FirebaseAdmin and classifies FCM's answers — an unregistered token is a dead device, a quota or server error is transient. Credentials come from the host through IFirebaseCredentialSource, so this package never decides where your service-account key lives.