Architecture Diagrams
Visual diagrams eliminate confusion and accelerate development in complex monorepos — showing exactly how data flows, components interact, and systems integrate.
Quick navigation
Why architecture diagrams matter
Without visual diagrams, developers face constant confusion:
- Lost in complexity — Monorepo has 85+ packages, 40+ apps, unclear relationships
- Integration uncertainty — Don't know how auth, analytics, AI, storage connect
- Data flow mystery — Unclear path from database → ORM → API → SDK → UI
- Debugging blindness — Can't trace errors through multiple system layers
- Onboarding nightmare — New developers spend weeks understanding architecture
- Documentation gaps — Text explanations fail to show visual relationships
OneApp's architecture diagrams provide 10 production-ready visual references — showing overall system architecture (5 stages), authentication flows (sessions + RBAC), API generation pipeline (Prisma → OpenAPI → SDK), data flows (database to UI), observability (error tracking + logs), CI/CD (quality gates + deployment), and real-world integration patterns (auth + analytics + AI).
Production-ready with Mermaid diagrams for live rendering, color-coded stages for clarity, interactive navigation in docs, integration with actual package names, complete data flow tracing from database to UI, error handling patterns with observability, and deployment pipeline visualization.
Use cases
Reference these diagrams to:
- Understand system architecture — See how 5 stages (UI → Server → Edge → Packages → Data) connect
- Trace data flows — Follow requests from client through API, ORM, database, back to UI
- Debug integration issues — Identify where auth, analytics, AI, storage interact
- Plan new features — Visualize how new components fit into existing architecture
- Onboard developers — Show visual overview instead of reading 85 doc files
- Document decisions — Reference specific diagrams in PRs and architecture decisions
Quick Start
1. Identify your need
Choose the right diagram for your task:
// Need to understand overall architecture?
→ See Diagram 1: Overall System Architecture
// Building authentication?
→ See Diagram 2: Authentication Flow
// Working with APIs?
→ See Diagram 3: API & SDK Generation Pipeline
// Integrating analytics?
→ See Diagram 4: User Authentication with Analytics
// Building AI features?
→ See Diagram 5: AI Chatbot with Guardrails
// Implementing feature flags?
→ See Diagram 6: Feature Flag Rollout & Measurement
// Building notifications?
→ See Diagram 7: Real-time Notification System
// Tracing data flows?
→ See Diagram 8: Data Flow (Database to UI)
// Debugging errors?
→ See Diagram 9: Observability & Error Tracking
// Understanding deployments?
→ See Diagram 10: Build & Deployment PipelineThat's it! You now know which diagram to reference.
2. Trace the flow
Follow the diagram arrows to understand data flow:
graph LR
A["📝 Your starting point"] --> B["🔧 Processing layer"]
B --> C["💾 Data storage"]
C --> D["📤 Output/Response"]That's it! Follow numbered steps or arrows to trace the complete flow.
3. Reference in documentation
Link to specific diagrams in your PRs and docs:
This PR implements authentication following the flow in
[Architecture Diagrams: Authentication Flow](/docs/guides/architecture-diagrams#2-authentication-flow)
The feature flag rollout follows
[Architecture Diagrams: Feature Flag Rollout](/docs/guides/architecture-diagrams#6-feature-flag-rollout--measurement)That's it! You can now reference diagrams in your documentation.
Complete diagram reference
All diagrams by category
System Architecture
| Diagram | Purpose |
|---|---|
| 1. Overall System Architecture → | 5-stage architecture (UI → Server → Edge → Packages → Data) |
| 8. Data Flow: Database to UI → | Complete pipeline from Prisma to React components |
| 10. Build & Deployment Pipeline → | CI/CD with quality gates and deployment flow |
Use when: Understanding system architecture, planning infrastructure, onboarding developers
Authentication & Authorization
| Diagram | Purpose |
|---|---|
| 2. Authentication Flow → | Complete auth flow with sessions, cookies, database |
| 4. User Authentication with Analytics → | Auth + analytics integration with user identification |
Use when: Implementing login, session management, user tracking
API & SDK Development
| Diagram | Purpose |
|---|---|
| 3. API & SDK Generation Pipeline → | Prisma → ORM → API → OpenAPI → TypeScript SDK (5 layers) |
Use when: Building APIs, generating SDKs, understanding type-safe data flow
AI & Advanced Features
| Diagram | Purpose |
|---|---|
| 5. AI Chatbot with Guardrails → | AI chat with safety, cost tracking, observability |
| 6. Feature Flag Rollout & Measurement → | Progressive rollout with impact measurement |
| 7. Real-time Notification System → | Notification generation, delivery, tracking |
Use when: Building AI features, implementing feature flags, sending notifications
Observability & Monitoring
| Diagram | Purpose |
|---|---|
| 9. Observability & Error Tracking → | Error capture, log aggregation, metrics visualization |
Use when: Debugging issues, monitoring production, tracking performance
System Architecture
1. Overall System Architecture
The OneApp monorepo is organized into 5 concurrent stages with clear boundaries:
graph TB
subgraph UI["🎨 UI Stage (Client)"]
Client["React Components<br/>Client Components<br/>Mantine + Tailwind"]
end
subgraph Server["🔧 Server Stage"]
RSC["React Server<br/>Components"]
Actions["Server Actions<br/>Route Handlers"]
end
subgraph Edge["⚡ Edge Stage"]
Middleware["Middleware<br/>Edge Functions"]
end
subgraph Packages["📦 Packages Stage"]
Auth["@repo/auth<br/>@repo/security"]
Analytics["@repo/analytics<br/>@repo/observability"]
AI["@repo/ai<br/>@repo/ai-oneapp"]
Storage["@repo/storage<br/>@repo/email"]
Utils["@repo/core-utils<br/>@repo/types"]
end
subgraph Data["💾 Data Stage"]
DB["@repo/db-prisma<br/>Prisma ORM"]
Redis["@repo/db-upstash-redis<br/>Cache & Queues"]
Vector["@repo/db-upstash-vector<br/>Vector Embeddings"]
end
subgraph Infra["🚀 Infrastructure"]
CI["GitHub Actions<br/>CI/CD"]
Deploy["Vercel<br/>Deployment"]
end
Client -->|uses| UI
Client -->|calls| Server
Server -->|uses| Packages
Edge -->|wraps| Server
Packages -->|queries| Data
CI -->|validates| Packages
Deploy -->|deploys| Infra
classDef uiStage fill:#6366f1
classDef serverStage fill:#8b5cf6
classDef edgeStage fill:#ec4899
classDef packageStage fill:#f59e0b
classDef dataStage fill:#10b981
classDef infraStage fill:#6b7280
class UI uiStage
class Server serverStage
class Edge edgeStage
class Packages packageStage
class Data dataStage
class Infra infraStageKey principles:
- UI Stage — Client components with React hooks, browser APIs (no server code)
- Server Stage — Server components, actions, route handlers (no client code)
- Edge Stage — Middleware wrapping server requests (minimal runtime)
- Packages Stage — Shared utilities with no React/Next.js dependencies
- Data Stage — Database, cache, vector storage with type-safe queries
- Infrastructure — CI/CD validation and deployment automation
8. Data Flow: From Database to UI
Complete data pipeline from database to rendered components:
graph TB
subgraph DB["💾 Database"]
PrismaDB["Prisma Schema<br/>Tables & Relations"]
end
subgraph ORM["🔧 ORM Layer"]
FindMany["findMany*Orm<br/>Query builder"]
FindUnique["findUnique*Orm<br/>Get by ID"]
end
subgraph Server["🔧 Server Layer"]
Action["Server Action<br/>or API Route"]
Validate["Validate<br/>with Zod"]
Transform["Transform Data<br/>for client"]
end
subgraph Client["🎨 Client Layer"]
Hook["useQuery Hook<br/>or useSWR"]
Cache["Cache Data<br/>React Query"]
Component["React Component<br/>Render UI"]
end
PrismaDB -->|query| FindMany
PrismaDB -->|by id| FindUnique
FindMany -->|execute| Action
FindUnique -->|execute| Action
Action -->|schema| Validate
Validate -->|success| Transform
Transform -->|JSON| Hook
Hook -->|cache| Cache
Cache -->|render| Component
classDef dbStage fill:#10b981,color:#fff
classDef ormStage fill:#f59e0b,color:#000
classDef serverStage fill:#8b5cf6,color:#fff
classDef clientStage fill:#6366f1,color:#fff
class DB dbStage
class ORM ormStage
class Server serverStage
class Client clientStageKey principles:
- Database — Prisma schema defines tables and relations
- ORM Layer — Generated functions with AsyncResult pattern
- Server Layer — Validates with Zod, transforms for client
- Client Layer — Caches with React Query, renders with React
10. Build & Deployment Pipeline
CI/CD flow with quality gates:
graph LR
subgraph Dev["💻 Development"]
Code["Commit Code"]
end
subgraph CI["🔍 CI Pipeline"]
Lint["Lint<br/>ESLint"]
Type["Type Check<br/>TypeScript"]
Test["Test<br/>Vitest"]
Coverage["Coverage<br/>Check"]
end
subgraph Quality["✅ Quality Gates"]
Pass["All Checks<br/>Pass?"]
end
subgraph Build["🏗️ Build"]
Next["Next.js Build<br/>Turbo"]
Package["Package Apps<br/>ESM/CJS"]
end
subgraph Deploy["🚀 Deployment"]
Staging["Deploy to<br/>Staging"]
Preview["Preview URLs"]
Prod["Deploy to<br/>Production"]
end
Code -->|push| Lint
Lint -->|pass| Type
Type -->|pass| Test
Test -->|pass| Coverage
Coverage -->|result| Pass
Pass -->|✓ yes| Next
Pass -->|✗ no| Code
Next -->|success| Package
Package -->|ready| Staging
Staging -->|generate| Preview
Preview -->|approved| Prod
classDef devStage fill:#fbbf24,color:#000
classDef ciStage fill:#ec4899,color:#fff
classDef qualityStage fill:#8b5cf6,color:#fff
classDef buildStage fill:#10b981,color:#fff
classDef deployStage fill:#6366f1,color:#fff
class Dev devStage
class CI ciStage
class Quality qualityStage
class Build buildStage
class Deploy deployStageKey principles:
- CI Pipeline — Lint, type check, test, coverage (must all pass)
- Quality Gates — Automatic enforcement prevents broken code
- Build — Next.js with Turbo for maximum performance
- Deployment — Staging → Preview → Production with approval
Authentication & Authorization
2. Authentication Flow
Complete authentication flow with teams and RBAC:
sequenceDiagram
actor User
participant Browser
participant App as "Next.js App"
participant Auth as "@repo/auth"
participant DB as "Prisma"
participant Session as "Session"
User->>Browser: Navigate to /login
Browser->>App: Request login page
App->>Browser: Render login form
User->>Browser: Enter credentials
Browser->>App: POST /api/auth/signin
App->>Auth: verifyCredentials()
Auth->>DB: Query user
DB->>Auth: User found
alt Credentials valid
Auth->>Session: Create session
Session->>Browser: Set secure cookie
Browser->>App: Redirect to /dashboard
App->>Auth: getSession()
Auth->>Browser: Authenticated dashboard
else Invalid credentials
Auth->>Browser: 401 Unauthorized
Browser->>User: Show error
endKey principles:
- Better Auth — Session-based authentication with secure cookies
- Database sessions — Stored in Prisma database for reliability
- Secure cookies — HttpOnly, SameSite=Lax, Secure in production
- Error handling — Clear messages without exposing internals
4. User Authentication with Analytics
How user actions flow through authentication and analytics:
graph TB
subgraph Client["🎨 Client"]
Login["Login Form"]
Track["Track Event"]
end
subgraph Auth["🔐 Authentication"]
Verify["Verify Credentials"]
CreateSession["Create Session"]
SetCookie["Set Auth Cookie"]
end
subgraph Analytics["📊 Analytics"]
Identify["Identify User"]
Emit["Emit Event"]
end
subgraph DB["💾 Database"]
UserTable["users table"]
SessionTable["sessions table"]
end
Login -->|POST /api/auth/signin| Verify
Verify -->|query| UserTable
UserTable -->|user data| CreateSession
CreateSession -->|write| SessionTable
SessionTable -->|✓ success| SetCookie
SetCookie -->|auth cookie| Client
Client -->|analytics.identify()| Identify
Identify -->|set context| Emit
Emit -->|send to PostHog| Analytics
classDef clientStage fill:#6366f1,color:#fff
classDef authStage fill:#8b5cf6,color:#fff
classDef analyticsStage fill:#ec4899,color:#fff
classDef dataStage fill:#10b981,color:#fff
class Client clientStage
class Auth authStage
class Analytics analyticsStage
class DB dataStageKey principles:
- Auth first — Complete authentication before tracking
- User identification — Call
analytics.identify()after login - Event tracking — Track login, signup, logout events
- PostHog integration — Automatic user context in all events
API & SDK Development
3. API & SDK Generation Pipeline
How Prisma schemas flow through ORM, API, and SDK layers:
graph LR
A["📝 Prisma Schema<br/>@repo/oneapp-shared<br/>prisma/schema.prisma"]
B["🔧 Prisma Generate<br/>prisma generate<br/>--schema=prisma"]
C["📦 ORM Layer<br/>@repo/oneapp-shared/orm<br/>Generated CRUD functions"]
D["🛣️ API Routes<br/>@repo/oneapp-api<br/>/api/v1/{schema}/{model}"]
E["📋 OpenAPI Spec<br/>prisma-openapi<br/>openapi.json"]
F["🎯 Path Generator<br/>Scans API routes<br/>Generates paths"]
G["🔗 Merge OpenAPI<br/>Combines schemas + paths<br/>openapi-complete.json"]
H["🎁 HeyAPI Generation<br/>openapi-ts<br/>Generates TypeScript"]
I["📚 SDK<br/>@repo/oneapp-sdk<br/>263 typed functions"]
J["💻 Client Code<br/>React Components<br/>Server Actions"]
A -->|generate| B
B -->|creates| C
C -->|powers| D
B -->|generates| E
D -->|scanned by| F
F -->|feeds| G
E -->|merged with| G
G -->|input to| H
H -->|generates| I
I -->|consumed by| J
classDef source fill:#fbbf24
classDef gen fill:#60a5fa
classDef output fill:#34d399
class A source
class B,F,H gen
class I,J outputKey principles:
- Single source of truth — Prisma schema defines everything
- 5 generation layers — Schema → ORM → API → OpenAPI → SDK
- Type safety — TypeScript types flow from database to UI
- Automatic updates — Regenerate when schema changes
See API SDK Integration guide for complete setup instructions.
AI & Advanced Features
5. AI Chatbot with Guardrails
Complete flow for AI chat with safety, cost tracking, and observability:
graph TB
subgraph Input["📝 Input & Validation"]
UserMsg["User Message"]
RateCheck["Rate Limit Check"]
SafetyCheck["Safety Guardrails<br/>Banned Topics"]
end
subgraph Processing["🤖 AI Processing"]
AIGen["Generate Response<br/>@repo/ai"]
Trace["Trace Metrics<br/>@repo/observability"]
Track["Track Usage<br/>@repo/analytics"]
end
subgraph Storage["💾 Data"]
SaveMsg["Save Message<br/>@repo/db-prisma"]
SaveCost["Save Cost<br/>Tokens + USD"]
end
subgraph Output["📤 Output"]
Stream["Stream Response"]
Display["Display Chat"]
end
UserMsg -->|check| RateCheck
RateCheck -->|check| SafetyCheck
SafetyCheck -->|✓ pass| AIGen
AIGen -->|metrics| Trace
Trace -->|tokens/latency| Track
Track -->|log event| SaveMsg
SaveMsg -->|log cost| SaveCost
SaveCost -->|return response| Stream
Stream -->|render| Display
SafetyCheck -->|❌ fail| Display
RateCheck -->|❌ blocked| Display
classDef inputStage fill:#f59e0b,color:#000
classDef processingStage fill:#8b5cf6,color:#fff
classDef storageStage fill:#10b981,color:#fff
classDef outputStage fill:#6366f1,color:#fff
class Input inputStage
class Processing processingStage
class Storage storageStage
class Output outputStageKey principles:
- Safety first — Rate limiting and banned topics before AI generation
- Cost tracking — Calculate USD cost from token usage
- Observability — Trace AI operations with spans and metrics
- Analytics — Track AI usage for product insights
See Cookbook Recipes: AI Chatbot for complete implementation.
6. Feature Flag Rollout & Measurement
Progressive rollout with impact measurement:
graph LR
subgraph Planning["📋 Planning"]
Plan["Define Feature<br/>Success Metrics"]
end
subgraph Rollout["🚀 Rollout"]
Flag["Set Feature Flag<br/>PostHog"]
Track["Track Exposure<br/>@repo/analytics"]
Percent["Gradual %<br/>0% → 100%"]
end
subgraph Measurement["📊 Measurement"]
Exposure["Exposure Data<br/>Who saw it?"]
Behavior["User Behavior<br/>What did they do?"]
Impact["Impact Analysis<br/>Did it help?"]
end
subgraph Decision["✅ Decision"]
Accept["Accept & Rollout<br/>100%"]
Reject["Reject & Rollback<br/>0%"]
Iterate["Iterate & Refine<br/>Adjust feature"]
end
Plan -->|configure| Flag
Flag -->|emit events| Track
Track -->|gradual increase| Percent
Percent -->|collect data| Exposure
Exposure -->|analyze behavior| Behavior
Behavior -->|calculate impact| Impact
Impact -->|positive result| Accept
Impact -->|negative result| Reject
Impact -->|mixed results| Iterate
classDef planning fill:#fbbf24,color:#000
classDef rollout fill:#8b5cf6,color:#fff
classDef measurement fill:#10b981,color:#fff
classDef decision fill:#6366f1,color:#fff
class Planning planning
class Rollout rollout
class Measurement measurement
class Decision decisionKey principles:
- Progressive rollout — Start at 0%, gradually increase to 100%
- Exposure tracking — Know exactly who saw the feature
- Impact analysis — Measure behavior changes and success metrics
- Data-driven decisions — Accept, reject, or iterate based on data
See Cookbook Recipes: Feature Flags for complete implementation.
7. Real-time Notification System
Notification generation, delivery, and tracking:
graph TB
subgraph Event["⚡ Event Trigger"]
Action["User Action<br/>e.g., Order placed"]
end
subgraph Generate["📝 Generate"]
Create["Create Notification<br/>@repo/db-prisma"]
Template["Select Template<br/>@repo/email"]
end
subgraph Deliver["📤 Delivery"]
Email["Send Email<br/>via Resend"]
WebSocket["Send WebSocket<br/>Real-time"]
end
subgraph Track["📊 Track"]
Sent["Mark Sent<br/>@repo/analytics"]
Opened["Track Open"]
Clicked["Track Click"]
Dismissed["Track Dismiss"]
end
subgraph Monitor["🔍 Monitor"]
Logs["Log Delivery<br/>@repo/observability"]
Metrics["Measure Rate<br/>Opens/Clicks"]
end
Action -->|trigger| Create
Create -->|render| Template
Template -->|send| Email
Template -->|emit| WebSocket
Email -->|log event| Sent
WebSocket -->|log event| Sent
Sent -->|user action| Opened
Opened -->|user action| Clicked
Opened -->|user action| Dismissed
Clicked -->|record| Logs
Dismissed -->|record| Logs
Logs -->|aggregate| Metrics
classDef eventStage fill:#f59e0b,color:#000
classDef generateStage fill:#8b5cf6,color:#fff
classDef deliverStage fill:#ec4899,color:#fff
classDef trackStage fill:#10b981,color:#fff
classDef monitorStage fill:#6366f1,color:#fff
class Event eventStage
class Generate generateStage
class Deliver deliverStage
class Track trackStage
class Monitor monitorStageKey principles:
- Event-driven — Trigger notifications from user actions
- Multi-channel — Email via Resend + WebSocket for real-time
- Engagement tracking — Open rates, click rates, dismissals
- Observability — Monitor delivery success and failure
See Cookbook Recipes: Notifications for complete implementation.
Observability & Monitoring
9. Observability & Error Tracking
How errors, logs, and metrics flow through the system:
graph TB
subgraph Sources["🔍 Event Sources"]
Errors["Errors<br/>try/catch"]
Logs["Log Messages<br/>logInfo/logError"]
Metrics["Metrics<br/>Performance data"]
WebVitals["Web Vitals<br/>LCP, FID, CLS"]
end
subgraph Collection["📦 Collection"]
Client["Client Collector<br/>Browser"]
Server["Server Collector<br/>Node.js"]
Edge["Edge Collector<br/>Middleware"]
end
subgraph Processing["⚙️ Processing"]
Sentry["Sentry<br/>Error tracking"]
BetterStack["BetterStack<br/>Log aggregation"]
PostHog["PostHog<br/>Analytics"]
end
subgraph Visualization["📊 Visualization"]
Dashboard["Dashboards"]
Alerts["Alerts"]
Reports["Reports"]
end
Errors -->|captured| Client
Logs -->|captured| Server
Logs -->|captured| Edge
Metrics -->|captured| Server
WebVitals -->|captured| Client
Client -->|batch send| Sentry
Server -->|send| BetterStack
Edge -->|send| Sentry
Server -->|emit| PostHog
Sentry -->|aggregate| Dashboard
BetterStack -->|aggregate| Dashboard
PostHog -->|aggregate| Dashboard
Dashboard -->|trigger| Alerts
Dashboard -->|generate| Reports
classDef sourcesStage fill:#f59e0b,color:#000
classDef collectionStage fill:#8b5cf6,color:#fff
classDef processingStage fill:#10b981,color:#fff
classDef visualizationStage fill:#6366f1,color:#fff
class Sources sourcesStage
class Collection collectionStage
class Processing processingStage
class Visualization visualizationStageKey principles:
- Multi-source — Errors, logs, metrics, Web Vitals all captured
- Layer-specific — Client (Sentry), Server (BetterStack), Edge (Sentry)
- Aggregation — Combined dashboards from multiple tools
- Actionable alerts — Trigger notifications for critical issues
Common Patterns
Contamination Prevention
graph TB
subgraph UI["🎨 UI Layer"]
Client["Client Components<br/>React hooks<br/>Browser APIs"]
end
subgraph Server["🔧 Server Layer"]
RSC["Server Components<br/>Database access<br/>Node.js APIs"]
end
subgraph Packages["📦 Packages"]
Universal["Universal<br/>No React/Next"]
end
UI -->|ALLOWED| Packages
Server -->|ALLOWED| Packages
Packages -->|FORBIDDEN| UI
Packages -->|FORBIDDEN| Server
UI -->|FORBIDDEN| Server
classDef allowed fill:#10b981,color:#fff
classDef forbidden fill:#ef4444,color:#fff
classDef package fill:#f59e0b,color:#000
class allowed
class forbidden
class packageKey principles:
- UI layer — Can use packages, CANNOT use server code
- Server layer — Can use packages, CANNOT be imported by UI
- Packages — Universal code with NO React/Next.js dependencies
See Workspace Architecture guide for enforcement rules.
Error Handling Pattern
graph TB
subgraph Try["🔧 Try Block"]
Code["Business Logic"]
end
subgraph Catch["❌ Catch Block"]
Log["Log Error<br/>@repo/observability"]
Track["Track Event<br/>@repo/analytics"]
Respond["Return Error<br/>Response"]
end
Code -->|error| Log
Log -->|add context| Track
Track -->|format| Respond
Respond -->|to client| User["User Sees<br/>Safe Message"]
classDef tryStage fill:#10b981,color:#fff
classDef catchStage fill:#ef4444,color:#fff
class Try tryStage
class Catch catchStageKey principles:
- Try block — Business logic that might fail
- Catch block — Log to observability, track to analytics, return safe message
- User experience — Never expose internal errors to users
See Error Handling guide for AsyncResult pattern.
Legend
- 🎨 UI Stage — React components, client-side logic
- 🔧 Server Stage — Server actions, API routes, database
- ⚡ Edge Stage — Middleware, edge functions
- 📦 Packages Stage — Shared utilities and libraries
- 💾 Data Stage — Database, cache, vectors
- 🚀 Infrastructure — CI/CD, deployment, hosting
Next steps
- Learn API generation: API SDK Integration →
- See real-world patterns: Cookbook Recipes →
- Understand data flow: Workspace Architecture →
For Developers: Working with Mermaid diagrams
Mermaid diagram syntax
All diagrams use Mermaid for live rendering in documentation.
Graph types
Flowchart (most common):
\`\`\`mermaid graph TB A["Start"] --> B["Process"] B --> C["End"] \`\`\`Sequence diagram (for temporal flows):
\`\`\`mermaid sequenceDiagram actor User participant App User->>App: Request App->>User: Response \`\`\`Subgraphs (for grouping):
\`\`\`mermaid graph TB subgraph Client["🎨 Client"] A["Component"] end
subgraph Server["🔧 Server"]
B["API"]
end
A --> B
\`\`\`Color coding
Stage colors used consistently across diagrams:
classDef uiStage fill:#6366f1 /* Indigo - UI layer */
classDef serverStage fill:#8b5cf6 /* Purple - Server layer */
classDef edgeStage fill:#ec4899 /* Pink - Edge layer */
classDef packageStage fill:#f59e0b /* Amber - Packages */
classDef dataStage fill:#10b981 /* Green - Data/Success */
classDef infraStage fill:#6b7280 /* Gray - Infrastructure */Semantic colors:
- 🟢 Green (
#10b981) — Success, data, allowed - 🔵 Blue (
#6366f1) — Client, output - 🟣 Purple (
#8b5cf6) — Server, processing - 🟡 Amber (
#f59e0b) — Warnings, packages, sources - 🔴 Red (
#ef4444) — Errors, forbidden - ⚫ Gray (
#6b7280) — Infrastructure, neutral
Best practices
Do:
- ✅ Use consistent stage colors across diagrams
- ✅ Keep diagrams focused (1 flow per diagram)
- ✅ Use emojis for quick visual identification
- ✅ Label arrows with action verbs ("query", "send", "generate")
- ✅ Group related components in subgraphs
- ✅ Show error paths with red arrows
Don't:
- ❌ Mix multiple flows in one diagram
- ❌ Use inconsistent naming (keep package names accurate)
- ❌ Omit labels on arrows (always explain relationships)
- ❌ Make diagrams too complex (split into multiple diagrams)
- ❌ Skip error paths (show failure cases)
Testing diagrams locally
1. Install Mermaid CLI (optional):
pnpm add -g @mermaid-js/mermaid-cli2. Generate PNG from Mermaid:
mmdc -i diagram.mmd -o diagram.png3. Preview in docs:
pnpm --filter=docs dev
# Visit http://localhost:3000/guides/architecture-diagramsContributing new diagrams
When to add diagrams
Add diagrams when:
- New architecture patterns — Team introduces new integration patterns
- Complex flows — Feature requires understanding of multiple system layers
- Onboarding gaps — New developers struggle with specific area
- Documentation requests — Multiple questions about same flow
Diagram contribution process
1. Identify need:
# Check if similar diagram exists
grep -r "mermaid" platform/apps/docs/content/400-guides/080-architecture-diagrams.mdx2. Create Mermaid diagram:
## 11. Your New Diagram Title
Description of what this diagram shows.
\`\`\`mermaid graph TB subgraph Stage1["🎨 Stage Name"] A["Component A"] end
subgraph Stage2["🔧 Another Stage"]
B["Component B"]
end
A -->|action| B
classDef stage1Color fill:#6366f1
classDef stage2Color fill:#8b5cf6
class Stage1 stage1Color
class Stage2 stage2Color
\`\`\`
**Key principles**:
- **Principle 1** — Explanation
- **Principle 2** — Explanation3. Add to diagram reference table:
Update the Complete diagram reference section with new entry.
4. Test rendering:
pnpm --filter=docs dev
# Verify diagram renders correctly5. Submit PR:
git add platform/apps/docs/content/400-guides/080-architecture-diagrams.mdx
git commit -m "docs: add diagram for [feature name]"
gh pr create --title "docs: add architecture diagram for [feature]"Related documentation
- Mermaid Documentation — Official Mermaid syntax guide
- Docusaurus Diagrams — How Docusaurus renders Mermaid
- Cookbook Recipes → — Implementation examples for these diagrams
- API SDK Integration → — Detailed guide for Diagram 3
Cookbook & Recipes
Real-world code recipes combining multiple OneApp packages — complete examples for authentication, analytics, AI, feature flags, and more.
Quick Reference
Concise cheat sheets for common tasks in OneApp packages — eliminate context-switching and ship features faster with copy-paste examples.