Report Schema Service
Component Detail
Description
Fetches the org-specific report field configuration JSON from Supabase and exposes a parsed, typed field schema. Caches the schema locally to prevent redundant network calls across report sessions within the same organisation context.
report-schema-service
Summaries
The Report Schema Service ensures that every organisation sees a reporting interface tailored to its specific operational context, without requiring engineering changes each time field requirements evolve. By dynamically fetching and caching org-specific field configurations from Supabase, the platform can serve multiple clients with distinct reporting needs from a single codebase. This reduces customisation costs, accelerates onboarding of new organisations, and gives operations teams the flexibility to update field structures without a full app release cycle.
This service is a foundational dependency for the entire report creation flow — no report can be rendered or submitted without a valid schema. Its medium complexity stems from the need to handle schema versioning, cache invalidation across sessions, and graceful degradation when network access is unavailable. The caching layer must be carefully tested across org-switching scenarios to prevent schema bleed between accounts. Any issues with the org-field-config-loader or Supabase connectivity will block report form rendering entirely, making this a high-priority integration risk to validate early in the delivery timeline.
The Report Schema Service runs exclusively in the mobile execution context and acts as the typed schema gateway for the report form rendering pipeline. It depends on report-schema-cache for local persistence and org-field-config-loader for remote fetching from Supabase. The four exposed interfaces — getSchema, refreshSchema, invalidateCache, and parseFieldConfig — cover the full cache lifecycle. parseFieldConfig should enforce strict typing against the report-field-schema data model, rejecting malformed configs with structured errors.
Cache invalidation strategy (TTL vs. explicit invalidation on org change) must be aligned with the session management layer to avoid stale schema renders after org context switches.
Responsibilities
- Fetch JSON field config from Supabase for the active org
- Parse and validate the schema into typed field definitions
- Cache schema per org to avoid redundant fetches
Interfaces
getSchema(orgId)
refreshSchema(orgId)
invalidateCache(orgId)
parseFieldConfig(json)
Relationships
Dependencies (2)
Components this component depends on
Related Data Entities (2)
Data entities managed by this component