SignalR mit API - welches Konzept

Guten Tag zusammen,

ich habe mich bisher noch wenig Erfahrung mit Echtzeit-Apps und hätte mal eine konzeptionelle Frage:
Ich habe eine WebApp die ihre Daten aus einer API bezieht.

Nun möchte ich für längere Tasks (Generierung von Berichten, Datenanalyse blablub) gerne eine Echtzeit-Fähigkeit implementieren, die dem User im Browser eine Push-Message anzeigt "Task XY finished, documents rdy".

Meinem Verständnis nach ist SignalR für die Kommunikation zwischen dem Service der WebApp und dem Browser des Users gedacht.
Nun ist die Frage: Woher weiß die WebApp, dass der Task in der API abgeschlossen ist? Kann ich hierfür einfach in der API ebenfalls einen SignalR-Hub aufsetzen in der die WebApp sich anmeldet?

Oder soll ich dem Browser sagen, dass er direkt die API als Hub benutzen soll? (klingt für mich nach einem konzeptbruch).

Beste Grüße
emuuu

Es gibt prinzipiell nicht nur eine konzeptionelle Richtung; da spielt auch viel das Verhalten des Frontends rein.

Was Du hier beschreibst ist eine asynchrone Kommunikation mit einem Eventverhalten; zB. CQS bzw CQRS - das wohl verbreiteste Konzept dazu.
Auf der anderen Seite basiert Dein Verständnis hier offenbar noch auf dem typischen Request-Response-Verhalten; und das passt nicht.
Das sind einfach zwei verschiedene Konzepte.

Technisch:
SignalR erstellt Hubs als Singleton.
Du kannst also problemlos mit Events in .NET den Hub konsumieren und so den Client informieren.

Wenn Du das mit klassischen Code Pattern machst, dann endet das aber oft in einem Depenendecy Chaos.
Daher musst Du bei Event Sourcing wie CQRS eben auch eine andere Software Architektur fahren damit es sauber(er) wird.

In .NET ist der am weitesten verbreitete Pattern dazu der Mediator-Pattern; dazu gibt es für InProcess-Handling das MediatR Projekt.