Portal Community

Configuration

stream.registerServer({
  id: 'notifications',
  type: 'bas',
  url: '/api/events/stream',
  transportConfig: {
    type: 'sse',
    url: '/api/events/stream',

    // Auth and filtering via query params
    queryParams: {
      token: authStore.getToken(),
      tenantId: tenantId,
    },
  }
});

Subscriptions Work Normally

From the subscriber's perspective, SSE is transparent — you subscribe the same way as any other transport:

// Subscribe to notifications — works identically for SSE, WebSocket, or SignalR
stream.subscribe('notifications', 'notification.*', (envelope) => {
  notificationStore.push({
    id: envelope.meta.id,
    topic: envelope.meta.topic,
    body: envelope.body,
    receivedAt: envelope.meta.receivedAt,
  });
});

Sending Data via HTTP

Since SSE is read-only, use a standard HTTP call for any client-to-server communication:

// SSE transport for receiving
stream.registerServer({
  id: 'notifications',
  type: 'bas',
  url: '/api/events/stream',
  transportConfig: { type: 'sse', url: '/api/events/stream', queryParams: { token } }
});

// Separate HTTP client for sending — do NOT call stream.send()
async function markNotificationRead(notificationId: string) {
  await fetch('/api/notifications/read', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${authStore.getToken()}` },
    body: JSON.stringify({ notificationId }),
  });
}
send() Throws on SSE Calling stream.send('notifications', ...) will throw an error: "Cannot send data via SSE transport (server-to-client only)". SSE is receive-only by design. Always pair an SSE transport with HTTP endpoints for outbound communication.

Event Types

SseTransport listens to both standard message and custom data event types from the server:

// Both of these server-sent event types are handled:
// data: {...}\n\n        → standard SSE message event
// event: data\n          → custom "data" event type

// Server-side (ASP.NET Core) example:
// await response.WriteAsync("data: " + json + "\n\n");

Reconnection

When the SSE connection drops (EventSource closes), SseTransport reconnects with exponential backoff — identical to the WebSocket transport's retry logic:

// Reconnect: 1s → 2s → 4s → 8s → 16s → 30s (capped)
// maxAttempts: 0 (unlimited by default)

Use Cases

ScenarioGood Fit for SSE?
Real-time notification feed (no replies needed)Yes — ideal
Live dashboard metrics (server pushes only)Yes — ideal
Chat with message repliesNo — use WebSocket or SignalR
Workflow events with form submissionsNo — use SignalR
Read-only audit event streamYes — ideal