Cloud Service Supabase Inc. Inbound
Websocket
Connection
Inbound
Data Flow
4
Components
3
Dependencies

Description

Supabase Realtime provides WebSocket-based push subscriptions to PostgreSQL change events, enabling the app to reflect database changes instantly without polling. Used for live expense claim approval status updates, in-app notification delivery, and coordinator visibility of pending attestation queues.

Detailed Analysis

Supabase Realtime transforms the coordinator experience by delivering instant visibility into pending expense approvals, attestation queues, and in-app notifications without requiring manual page refreshes. For a platform where timely approval of expense claims directly affects peer mentors' ability to operate in the field, sub-500ms push notifications for approval status changes materially improve operational responsiveness. Coordinators gain a live dashboard reflecting the current state of their organisation's activity, reducing the risk of missed approvals that could delay reimbursement for vulnerable individuals. The integration is included in the Supabase Pro subscription with graceful degradation to polling — meaning a Realtime service disruption does not block any business process, only reduces immediacy.

This positions the feature as a quality-of-life enhancement with zero hard-dependency risk to core operations.

Realtime integration touches four components: approval subscriptions, notification delivery, in-app banner display, and the central Realtime subscription service. Setup requires enabling Realtime on specific database tables (expense_claims, notifications) in the Supabase dashboard and configuring per-user/organisation channel filter expressions — a configuration step that must be coordinated with the database schema finalisation. The fallback to 30-second polling when WebSocket is unavailable must be explicitly implemented and tested, particularly for low-connectivity field scenarios. WebSocket reconnect backoff configuration and channel subscription state restoration on reconnect are edge cases requiring dedicated QA attention.

Capacity planning should confirm that concurrent WebSocket connections remain within the Supabase Pro limit of 500. Ongoing monitoring should track reconnect frequency as a signal of network quality issues in the user population. This integration has low maintenance overhead once configured, as Supabase manages the WebSocket infrastructure.

Supabase Realtime v2 uses the supabase_flutter SDK's channel API to subscribe to PostgreSQL change events (INSERT/UPDATE on expense_claims and notifications tables) via WebSocket. Subscriptions are scoped using filter expressions that match RLS policies — users receive only events for rows they own, enforced server-side on the Realtime service. The 507-supabase-realtime-subscription-service manages channel lifecycle including subscribe, unsubscribe, and reconnect. Automatic WebSocket reconnect uses exponential backoff; after repeated failures, the system falls back to polling at 30-second intervals via the same data-fetching layer.

Channel subscription state is tracked in memory and restored on reconnect to prevent missed events during transient disconnections. The 290-realtime-approval-subscription component listens specifically for claim status changes and pushes updates to the UI reactively. Realtime payloads intentionally contain only row IDs and status fields — no PII is transmitted via the WebSocket channel, with full data fetched via a subsequent authenticated database query. Connection state is monitored in-app and surfaced to the user when degraded.

Dependencies (3)

supabase_flutter SDK with Realtime channel support External
WebSocket-capable network connection External
Supabase Realtime enabled on Supabase project External

Authentication

TypeJwt
RequirementsActive authenticated Supabase session, Realtime enabled on target tables in Supabase dashboard
Scopesrealtime:read (filtered by RLS)

Configuration

Required Settings

Realtime enabled for target tables (expense_claims, notifications) Required
Channel filter expressions per user/organisation Required

Optional Settings

Reconnect backoff configuration Optional
Broadcast vs Postgres changes mode Optional

Environment Variables

SUPABASE_URL
SUPABASE_ANON_KEY

Error Handling

Automatic WebSocket reconnect with exponential backoff
Fall back to polling on repeated WebSocket failure
Channel subscription state tracked and restored on reconnect

Monitoring

Health Checks

WebSocket connection state monitoring in app
Supabase Realtime service health via status page

Metrics

Active WebSocket connections
Message delivery latency
Reconnect frequency

Alerts

Realtime service degradation
Message queue backlog growing

Performance

Latency< 500ms for approval status push to coordinator
AvailabilityGraceful degradation to polling acceptable — not hard dependency

Rate Limits

Supabase Pro: 500 concurrent Realtime connections
200 messages per second per channel

Cost Implications

Pricing ModelIncluded in Supabase Pro plan; overage billing for peak concurrent connections

Cost Factors

Concurrent WebSocket connections
Messages per month

Security Considerations

RLS policies enforced on Realtime subscriptions — users only receive events for their own rows
JWT validated on every channel subscription
No sensitive PII transmitted via Realtime payloads — only row IDs and status fields

Fallback Mechanisms

Polling fallback at 30-second intervals when WebSocket unavailable
Manual pull-to-refresh available in all list views