Infrastructure low complexity Shared Component frontendmobile
0
Dependencies
5
Dependents
0
Entities
1
Integrations

Description

Riverpod provider exposing the initialized Supabase client instance to all repository layers. Centralizes client configuration and session management. Shared across all features that access the Supabase backend.

Feature: Peer Mentor Profile & Status Screen

supabase-client-provider

Summaries

The Supabase Client Provider is the foundational infrastructure component that connects every feature of the application to its backend data and authentication services. By centralizing the Supabase connection into a single managed provider, the platform ensures consistent, secure access to all organizational data without duplicating connection logic across features. This reduces the risk of authentication failures, session expiry issues, or misconfigured API keys appearing in production. As a shared component used by every repository in the system, its reliability directly determines the uptime and data integrity of the entire application, making it one of the highest-impact infrastructure investments in the project.

As a shared infrastructure component with zero external dependencies, the Supabase Client Provider must be one of the first components delivered since every other repository depends on it. Its low complexity means it can be completed early in the project timeline, unblocking all data-layer work in parallel. The component manages session lifecycle and token refresh, which requires thorough testing of authentication edge cases: expired tokens, network interruptions during refresh, and initial cold-start initialization. Deployment requires the Supabase project URL and anon key to be injected at build time or via environment configuration.

Any delays or instability in this component will cascade across all features, so it should be treated as a critical path item despite its low complexity.

Implemented as a Riverpod provider exposing a SupabaseClient singleton initialized with the project URL and anonymous key. The initialize method should be called once at app startup (typically in main.dart before runApp). Use Riverpod's Provider or StateNotifierProvider to expose the client instance; all repository providers should declare supabaseClientProvider as a dependency via ref.watch or ref.read. The authStateChanges stream exposes Supabase's built-in auth state events for login, logout, and token refresh.

Token refresh is handled automatically by the Supabase Flutter SDK, but you should handle AuthException in repositories gracefully. Avoid exposing the raw SupabaseClient in UI layers; keep it confined to the repository layer for clean separation of concerns.

Responsibilities

  • Provide initialized SupabaseClient singleton via Riverpod
  • Manage Supabase session lifecycle and token refresh
  • Expose typed query helpers for common Supabase patterns

Interfaces

supabaseClientProvider
SupabaseClient get client
Future<void> initialize({required String url, required String anonKey})
Stream<AuthState> authStateChanges

Used Integrations (1)

External integrations and APIs this component relies on

API Contract

View full contract →
REST /api/v1/auth 5 endpoints
GET /api/v1/auth/session Get current authenticated session and auth state
GET /api/v1/auth/state Get current auth state enum value
POST /api/v1/auth/initialize Initialize Supabase client connection
PUT /api/v1/auth/session Refresh current session token
DELETE /api/v1/auth/session Sign out and invalidate current session