Platform Architecture
Relevant source files
The following files were used as context for generating this wiki page:
The Monarch Property Management platform is an enterprise-grade property management system designed to facilitate interactions between administrators, vendors, and tenants. The architecture is built on a modern decoupled stack, utilizing React for the frontend, Supabase for backend-as-a-service (BaaS), and a token-driven design system for consistent UI/UX across all modules.
The system's scope encompasses tenant management, vendor coordination, maintenance tracking, and a complex Request for Quotation (RFQ) engine. Security is enforced through a multi-layered approach involving Role-Based Access Control (RBAC) on the frontend and Row-Level Security (RLS) on the database tier.
Sources: src/App.tsx, src/design-system/README.md:1-10, DEPLOYMENT_GUIDE.md:10-25
Core Architectural Layers
Frontend Architecture
The frontend is a Single Page Application (SPA) built with React and TypeScript, leveraging Vite for the build process. It utilizes a lazy-loading strategy to optimize the initial bundle size, particularly for complex administrative and vendor modules.
- Routing & RBAC: Centralized routing is managed in
src/App.tsx, where anOptimizedProtectedRoutecomponent enforces role requirements (admin,vendor,tenant). - State Management: The application uses TanStack Query for server-state synchronization and standardized hooks for localized data fetching (e.g.,
useRFQDetail). - Performance: Critical CSS is inlined in
index.htmlto eliminate render-blocking, and resource hints likepreconnectare used for the Supabase API and Google Fonts.
Sources: src/App.tsx:15-60, index.html:5-20, src/pages/admin/RFQEdit.tsx:150-170
Backend & Security Hardening
The backend relies on Supabase for authentication, real-time messaging, and database management. A significant "Backend Security Hardening" layer was implemented to ensure multi-tenant data protection.
- Row-Level Security (RLS): Over 15+ policies ensure that vendors can only see their own bids and tenants can only see their own leases.
- Database Objects: The system uses 8 performance indexes and 5
SECURITY DEFINERhelper functions to bypass RLS in controlled scenarios (e.g., identity verification). - Edge Functions: Server-side logic, such as sitemap generation and automated email invitations, is handled by Deno-based Supabase Edge Functions.
Sources: DEPLOYMENT_GUIDE.md:30-60, supabase/functions/generate-sitemap/index.ts:1-20
Data Infrastructure
The platform's data model is centered around the Request for Quotation (RFQ) and Project lifecycles.
| Component | Description | Key Fields |
|---|---|---|
| RFQs | The central document for property projects. | title, document_control, building_details, system_strategy |
| Bids | Vendor responses to specific RFQ lots. | vendor_id, unit_price, submitted_at |
| Projects | Active maintenance or development tasks. | status, priority, budget_range, location |
| Properties | Managed real estate listings. | id, title, address, status |
Sources: src/pages/admin/RFQEdit.tsx:40-100, src/components/AdminProjectCreationForm.tsx:50-70
RFQ Data Structure
The RFQ engine utilizes a complex JSON-based configuration to handle building specifications and technical requirements.
interface RFQFormData {
title: string;
status: string;
document_control: {
rfq_reference: string;
project_name: string;
issuer: string;
};
building_details: {
building_type: string;
floors: number;
residential_units: number;
};
budget_guidance: {
installation_min: number;
installation_max: number;
};
}
Sources: src/pages/admin/RFQEdit.tsx:44-125
Design System & Theming
The "Monarch Design System" follows a token-driven architecture where visual properties are defined in a centralized tokens.json.
- Phase 1 Foundation: Establishes semantic colors (success, warning, error, info) that meet WCAG 2.2 AA compliance standards.
- Theme Provider: Wraps
next-themesto detect system preferences (prefers-color-scheme) and reduced motion preferences (prefers-reduced-motion). - Tailwind Integration: CSS custom properties are mapped to Tailwind config, allowing for real-time theme switching without page reloads.
Sources: src/design-system/README.md:15-45, src/index.css:5-50
Request Lifecycle Diagram
The following diagram illustrates how a user request is authenticated, authorized, and served by the database layer.
RFQ & Bid Interaction Flow
The interaction between Administrators and Vendors is handled through a sequence of invitations and bid submissions.
Performance & Optimization
To maintain high performance on mobile devices and notched displays, the platform implements specific CSS and HTML optimizations:
- Critical Path: Inlined styles for the Hero section and Navbar in
index.htmlto achieve a faster First Contentful Paint (FCP). - Safe Areas: CSS utilities for
safe-area-insetensure the UI remains accessible on mobile devices with notches. - Database Indexes: 8 specific indexes (e.g.,
idx_vendor_bids_vendor_id) were added to improve query times by 20x to 100x compared to unindexed lookups. - Rate Limiting: Edge functions like the sitemap generator include in-memory rate limiting to prevent DDoS or excessive resource consumption.
Sources: index.html:50-100, src/index.css:450-480, DEPLOYMENT_GUIDE.md:175-185, supabase/functions/generate-sitemap/index.ts:7-25
Conclusion
The architecture of the Monarch Property Management platform is designed for security and scalability. By combining a token-driven frontend with a hardened Supabase backend, the system ensures that complex data operations—such as RFQ management and bid analysis—are performed efficiently while maintaining strict data isolation across different user roles.