|
| 1 | +### **1. High-Level System Architecture** |
| 2 | + |
| 3 | +This diagram focuses strictly on system boundaries, logical grouping, and the primary flow of data. Implementation details and workflows have been abstracted away to provide a clean 30-second overview of the stack. |
| 4 | + |
| 5 | +```mermaid |
| 6 | +flowchart TD |
| 7 | + classDef frontend fill:#3b82f6,color:#fff,stroke:#1d4ed8,stroke-width:2px |
| 8 | + classDef core fill:#8b5cf6,color:#fff,stroke:#6d28d9,stroke-width:2px |
| 9 | + classDef module fill:#10b981,color:#fff,stroke:#047857,stroke-width:2px |
| 10 | + classDef engine fill:#f59e0b,color:#fff,stroke:#d97706,stroke-width:2px |
| 11 | + classDef storage fill:#64748b,color:#fff,stroke:#475569,stroke-width:2px |
| 12 | +
|
| 13 | + Browser[Client UI <br> PicoCSS / Alpine / HTMX]:::frontend |
| 14 | + |
| 15 | + subgraph Core Server [Go Backend] |
| 16 | + Router[Chi Router & Middleware]:::core |
| 17 | + Auth[Session Store]:::core |
| 18 | + end |
| 19 | + |
| 20 | + subgraph Business Modules |
| 21 | + CRM[Clients]:::module |
| 22 | + Billing[Quotes / Invoices / Payments]:::module |
| 23 | + Dash[Dashboard Aggregator]:::module |
| 24 | + end |
| 25 | + |
| 26 | + subgraph Technical Engines |
| 27 | + Calc[3D Cost Calculator]:::engine |
| 28 | + PDF[PDF Renderer]:::engine |
| 29 | + Mail[SMTP Mailer]:::engine |
| 30 | + Workers[Background Workers]:::engine |
| 31 | + end |
| 32 | +
|
| 33 | + DB[(SQLite WAL)]:::storage |
| 34 | +
|
| 35 | + Browser -->|HTTP Requests| Router |
| 36 | + Router -->|Authenticate| Auth |
| 37 | + Router -->|Route to| Business Modules |
| 38 | + |
| 39 | + Business Modules -->|Trigger| Technical Engines |
| 40 | + Business Modules <-->|Read / Write| DB |
| 41 | + Technical Engines -.->|Read / Write| DB |
| 42 | + Auth <-->|Verify| DB |
| 43 | +
|
| 44 | +``` |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +### **2. Request Lifecycle & Authentication Flow** |
| 49 | + |
| 50 | +Instead of mapping every single router connection to a database node, this sequence diagram explains the general pattern every request follows. |
| 51 | + |
| 52 | +```mermaid |
| 53 | +sequenceDiagram |
| 54 | + actor Client |
| 55 | + participant App as App (HTMX/JS) |
| 56 | + participant Router as Chi Router |
| 57 | + participant Session as Session Store |
| 58 | + participant DB as SQLite |
| 59 | + participant Handler as Business Handler |
| 60 | +
|
| 61 | + Client->>App: Interaction |
| 62 | + App->>Router: HTTP Request |
| 63 | + Router->>Session: Validate Middleware |
| 64 | + Session->>DB: Check Token |
| 65 | + DB-->>Session: Token Valid |
| 66 | + Router->>Handler: Forward Request |
| 67 | + Handler->>DB: Execute Query |
| 68 | + DB-->>Handler: Result Set |
| 69 | + Handler-->>App: Render HTML Snippet |
| 70 | + App-->>Client: Update UI |
| 71 | +
|
| 72 | +``` |
| 73 | + |
| 74 | +--- |
| 75 | + |
| 76 | +### **3. Quote to Invoice Conversion** |
| 77 | + |
| 78 | +This abstracts the "1-Click Convert" logic into a dedicated process flow, showing exactly how state is transferred from an estimate to a billable entity. |
| 79 | + |
| 80 | +```mermaid |
| 81 | +sequenceDiagram |
| 82 | + actor User |
| 83 | + participant Q as Quotes Module |
| 84 | + participant I as Invoices Module |
| 85 | + participant DB as SQLite |
| 86 | +
|
| 87 | + User->>Q: Click "Convert to Invoice" |
| 88 | + Q->>DB: Fetch Quote Details |
| 89 | + DB-->>Q: Quote Data |
| 90 | + Q->>I: Initialize Draft Invoice |
| 91 | + I->>DB: Duplicate Line Items (Preserve 3D Print Type) |
| 92 | + DB-->>I: Save Confirmed |
| 93 | + I-->>User: Redirect to Invoice Editor |
| 94 | +
|
| 95 | +``` |
| 96 | + |
| 97 | +--- |
| 98 | + |
| 99 | +### **4. 3D Print Cost Calculation Flow** |
| 100 | + |
| 101 | +The cost calculator serves two distinct purposes: generating a live UI preview and officially logging a print job. This sequence diagram clarifies that dual behavior. |
| 102 | + |
| 103 | +```mermaid |
| 104 | +sequenceDiagram |
| 105 | + participant UI as Browser (HTMX) |
| 106 | + participant Calc as Cost Engine |
| 107 | + participant DB as SQLite |
| 108 | +
|
| 109 | + UI->>Calc: POST Print Parameters |
| 110 | + Note over Calc: Calculate: Base Cost + Markups <br/> Machine Time + Failure Buffer |
| 111 | + |
| 112 | + alt Live Preview Request |
| 113 | + Calc-->>UI: Render Formatted Cost HTML |
| 114 | + else Save Print Job Request |
| 115 | + Calc->>Calc: Format Multi-line Description |
| 116 | + Calc->>DB: Save Detailed Line Item |
| 117 | + DB-->>Calc: Confirm Insert |
| 118 | + Calc-->>UI: Append Line Item to View |
| 119 | + end |
| 120 | +
|
| 121 | +``` |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +### **5. PDF Generation & Debounced Mailer Workflow** |
| 126 | + |
| 127 | +Debouncing and background processing are notoriously hard to represent in a top-down graph. A sequence diagram perfectly captures the timing mechanism and background hand-offs. |
| 128 | + |
| 129 | +```mermaid |
| 130 | +sequenceDiagram |
| 131 | + participant UI as Browser |
| 132 | + participant Inv as Invoice Module |
| 133 | + participant Debounce as Worker |
| 134 | + participant PDF as Chromedp |
| 135 | + participant SMTP as Mailer Engine |
| 136 | + actor Inbox as Client Email |
| 137 | +
|
| 138 | + UI->>Inv: Save Line Item (Keystroke) |
| 139 | + Inv->>Debounce: Emit Save Event |
| 140 | + Note over Debounce: Wait 5 Seconds<br/>(Drop rapid successive events) |
| 141 | + Debounce->>PDF: Trigger Headless Render |
| 142 | + PDF-->>Debounce: Compiled PDF Bytes |
| 143 | + Debounce->>SMTP: Dispatch Payload |
| 144 | + SMTP->>Inbox: Deliver Email + Attachment |
| 145 | +
|
| 146 | +``` |
0 commit comments