OneApp Docs
Guides

Architecture Diagrams

Visual diagrams eliminate confusion and accelerate development in complex monorepos — showing exactly how data flows, components interact, and systems integrate.

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 Pipeline

That'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

DiagramPurpose
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

DiagramPurpose
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

DiagramPurpose
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

DiagramPurpose
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

DiagramPurpose
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 infraStage

Key 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 clientStage

Key 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 deployStage

Key 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
    end

Key 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 dataStage

Key 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 output

Key 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 outputStage

Key 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 decision

Key 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 monitorStage

Key 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 visualizationStage

Key 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 package

Key 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 catchStage

Key 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

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-cli

2. Generate PNG from Mermaid:

mmdc -i diagram.mmd -o diagram.png

3. Preview in docs:

pnpm --filter=docs dev
# Visit http://localhost:3000/guides/architecture-diagrams

Contributing 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.mdx

2. 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** — Explanation

3. Add to diagram reference table:

Update the Complete diagram reference section with new entry.

4. Test rendering:

pnpm --filter=docs dev
# Verify diagram renders correctly

5. 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]"

On this page