159 lines
5.3 KiB
Markdown
159 lines
5.3 KiB
Markdown
|
|
# Customer Portal Architecture
|
||
|
|
|
||
|
|
## 🏗️ **System Overview**
|
||
|
|
|
||
|
|
The Customer Portal is a modern monorepo with clean separation between frontend (Next.js) and backend (NestJS), designed for maintainability and scalability.
|
||
|
|
|
||
|
|
### **High-Level Structure**
|
||
|
|
|
||
|
|
```
|
||
|
|
apps/
|
||
|
|
portal/ # Next.js frontend
|
||
|
|
bff/ # NestJS Backend-for-Frontend
|
||
|
|
packages/
|
||
|
|
domain/ # Pure domain/types/utils (isomorphic)
|
||
|
|
logging/ # Centralized logging utilities
|
||
|
|
validation/ # Shared validation schemas
|
||
|
|
```
|
||
|
|
|
||
|
|
## 🎯 **Architecture Principles**
|
||
|
|
|
||
|
|
### **1. Separation of Concerns**
|
||
|
|
- **Dev vs Prod**: Clear separation with appropriate tooling
|
||
|
|
- **Services vs Apps**: Development runs apps locally, production containerizes everything
|
||
|
|
- **Configuration vs Code**: Environment variables for configuration, code for logic
|
||
|
|
|
||
|
|
### **2. Single Source of Truth**
|
||
|
|
- **One environment template**: `.env.example`
|
||
|
|
- **One Docker Compose** per environment
|
||
|
|
- **One script** per operation type
|
||
|
|
|
||
|
|
### **3. Clean Dependencies**
|
||
|
|
- **Portal**: Uses `@/lib/*` for shared utilities and services
|
||
|
|
- **BFF**: Feature-aligned modules with shared concerns in `src/common/`
|
||
|
|
- **Domain**: Framework-agnostic types and utilities
|
||
|
|
|
||
|
|
## 🚀 **Portal (Next.js) Architecture**
|
||
|
|
|
||
|
|
```
|
||
|
|
src/
|
||
|
|
app/ # App Router routes
|
||
|
|
components/ # Design system (atomic design)
|
||
|
|
atoms/ # Basic UI elements
|
||
|
|
molecules/ # Component combinations
|
||
|
|
organisms/ # Complex UI sections
|
||
|
|
templates/ # Page layouts
|
||
|
|
features/ # Feature modules (auth, billing, etc.)
|
||
|
|
lib/ # Core utilities and services
|
||
|
|
api/ # OpenAPI client with type generation
|
||
|
|
hooks/ # Shared React hooks
|
||
|
|
utils/ # Utility functions
|
||
|
|
providers/ # Context providers
|
||
|
|
styles/ # Global styles
|
||
|
|
```
|
||
|
|
|
||
|
|
### **Conventions**
|
||
|
|
- Use `@/lib/*` for shared frontend utilities and services
|
||
|
|
- Feature modules own their `components/`, `hooks/`, `services/`, and `types/`
|
||
|
|
- Cross-feature UI belongs in `components/` (atomic design)
|
||
|
|
- Avoid duplicate layers - no `core/` or `shared/` inside apps
|
||
|
|
|
||
|
|
## 🔧 **BFF (NestJS) Architecture**
|
||
|
|
|
||
|
|
```
|
||
|
|
src/
|
||
|
|
modules/ # Feature-aligned modules
|
||
|
|
auth/ # Authentication
|
||
|
|
billing/ # Invoice and payment management
|
||
|
|
catalog/ # Product catalog
|
||
|
|
orders/ # Order processing
|
||
|
|
subscriptions/ # Service management
|
||
|
|
core/ # Core services and utilities
|
||
|
|
integrations/ # External service integrations
|
||
|
|
salesforce/ # Salesforce CRM integration
|
||
|
|
whmcs/ # WHMCS billing integration
|
||
|
|
common/ # Nest providers/interceptors/guards
|
||
|
|
main.ts # Application entry point
|
||
|
|
```
|
||
|
|
|
||
|
|
### **Conventions**
|
||
|
|
- Prefer `modules/*` over flat directories per domain
|
||
|
|
- Keep DTOs and validators in-module
|
||
|
|
- Reuse `packages/domain` for domain types
|
||
|
|
- External integrations in dedicated modules
|
||
|
|
|
||
|
|
## 📦 **Shared Packages**
|
||
|
|
|
||
|
|
### **Domain Package**
|
||
|
|
- **Purpose**: Framework-agnostic domain models and types
|
||
|
|
- **Contents**: Status enums, validation helpers, business types
|
||
|
|
- **Rule**: No React/NestJS imports allowed
|
||
|
|
|
||
|
|
### **Logging Package**
|
||
|
|
- **Purpose**: Centralized structured logging
|
||
|
|
- **Features**: Pino-based logging with correlation IDs
|
||
|
|
- **Security**: Automatic PII redaction [[memory:6689308]]
|
||
|
|
|
||
|
|
### **Validation Package**
|
||
|
|
- **Purpose**: Shared Zod validation schemas
|
||
|
|
- **Usage**: Form validation, API request/response validation
|
||
|
|
|
||
|
|
## 🔗 **Integration Architecture**
|
||
|
|
|
||
|
|
### **API Client**
|
||
|
|
- **Implementation**: OpenAPI-based with `openapi-fetch`
|
||
|
|
- **Features**: Automatic type generation, CSRF protection, auth handling
|
||
|
|
- **Location**: `apps/portal/src/lib/api/`
|
||
|
|
|
||
|
|
### **External Services**
|
||
|
|
- **WHMCS**: Billing system integration
|
||
|
|
- **Salesforce**: CRM and order management
|
||
|
|
- **Redis**: Caching and session storage
|
||
|
|
- **PostgreSQL**: Primary data store
|
||
|
|
|
||
|
|
## 🔒 **Security Architecture**
|
||
|
|
|
||
|
|
### **Authentication Flow**
|
||
|
|
- Portal-native authentication with JWT tokens
|
||
|
|
- Optional MFA support
|
||
|
|
- Secure token rotation with Redis backing
|
||
|
|
|
||
|
|
### **Error Handling**
|
||
|
|
- Never leak sensitive details to end users [[memory:6689308]]
|
||
|
|
- Centralized error mapping to user-friendly messages
|
||
|
|
- Comprehensive audit trails
|
||
|
|
|
||
|
|
### **Data Protection**
|
||
|
|
- PII minimization with encryption at rest/in transit
|
||
|
|
- Row-level security (users can only access their data)
|
||
|
|
- Idempotency keys on all mutating operations
|
||
|
|
|
||
|
|
## 🚀 **Development Workflow**
|
||
|
|
|
||
|
|
### **Path Aliases**
|
||
|
|
- **Portal**: `@/*`, `@/lib/*`, `@/features/*`, `@/components/*`
|
||
|
|
- **BFF**: `@/*` mapped to `apps/bff/src`
|
||
|
|
- **Domain**: Import via `@customer-portal/domain`
|
||
|
|
|
||
|
|
### **Code Quality**
|
||
|
|
- Strict TypeScript rules enforced repository-wide
|
||
|
|
- ESLint and Prettier for consistent formatting
|
||
|
|
- Pre-commit hooks for quality gates
|
||
|
|
|
||
|
|
## 📈 **Performance & Scalability**
|
||
|
|
|
||
|
|
### **Caching Strategy**
|
||
|
|
- **Invoices**: 60-120s per page; bust on WHMCS webhook
|
||
|
|
- **Cases**: 30-60s; bust after create/update
|
||
|
|
- **Catalog**: 5-15m; manual bust on changes
|
||
|
|
- **Keys include user_id** to prevent cross-user leakage
|
||
|
|
|
||
|
|
### **Database Optimization**
|
||
|
|
- Connection pooling with Prisma
|
||
|
|
- Proper indexing on frequently queried fields
|
||
|
|
- Optional mirrors for external system data
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
*This architecture supports clean, maintainable code with clear separation of concerns and production-ready security.*
|