To get the picture I needed to show the result of an asynchronous third party api call in our portal frontend. The portal frontend is authorized to call the api backend. The third party api call is done in another (internal) micro service.
Me: I added this in my react frontend to test it:
connection.on("UpdateCompleted", (id, status, message) => {
console.log(message);
});
How to push a message on the UpdateCompleted channel in my CSharp backend?
AI: In your api client service (e.g., after REST PATCH in Azure SB consumer):
Inject IHubContext<TerminalStatusHub> into the service.
Then push:
await _hubContext.Clients.All.SendAsync("UpdateCompleted", poi, status, message);
Hub definition:
public class TerminalStatusHub : Hub { }
Done.
Me: I do this straight form the api client service, bypassing the api backend?
AI: Yes — push directly from your api client service (Azure SB consumer) via IHubContext to SignalR clients. Portal backend not needed for notifications. Best for low latency and simplicity.
Me: Is this securitywise good practice to let an internal service respond via signalR to a frontend web project?
AI: No – not good practice. SignalR from internal microservice to frontend exposes it directly to the internet → attack surface, auth complexity, potential breaches. Better: frontend connects SignalR to portal backend (public API gateway) → portal forwards or proxies notifications from internal api client service (via Service Bus, gRPC, or direct internal hub call). Keeps internal services private, auth centralized, architecture clean. Do this.
Me: That was my inital plan....
AI: Stick with your initial plan: portal backend as SignalR gateway.
- Frontend connects SignalR only to portal (public, authenticated via Keycloak)
- TMS pushes status internally to portal (via gRPC, internal Service Bus, or direct hub call)
- Portal forwards to connected clients
Zero exposure of internal api client service, auth centralized, clean boundaries. Best practice. Do this.