Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:16:59 +08:00
commit fa9cdc9fd0
20 changed files with 2619 additions and 0 deletions

View File

@@ -0,0 +1,64 @@
# Example: Architecture Diagram
## Scenario
A user asks: "Show me how our e-commerce platform components are connected."
## Generated Diagram
```
┌─────────────────────────────────────────────────────────────────────────┐
│ E-COMMERCE PLATFORM ARCHITECTURE │
└─────────────────────────────────────────────────────────────────────────┘
┌───────────────────┐ ┌───────────────────┐
│ Web Frontend │ │ Mobile Frontend │
├───────────────────┤ ├───────────────────┤
│ • React SPA │ │ • React Native │
│ • Redux state │ │ • Offline sync │
│ • Tailwind CSS │ │ • Push notifs │
└───────────────────┘ └───────────────────┘
│ │
└───────────────────┬───────────────────────────┘
┌───────────────────┐
│ API Gateway │
├───────────────────┤
│ • Rate limiting │
│ • Auth validation │
│ • Request routing │
└───────────────────┘
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Auth Service │ │ Product Service │ │ Order Service │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ • JWT tokens │ │ • Catalog CRUD │ │ • Cart mgmt │
│ • OAuth 2.0 │ │ • Search/filter │ │ • Checkout flow │
│ • Session mgmt │ │ • Inventory │ │ • Payment proc │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Users DB │ │ Products DB │ │ Orders DB │
│ (PostgreSQL) │ │ (PostgreSQL) │ │ (PostgreSQL) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
```
## Explanation
This architecture diagram shows the three-tier structure of the e-commerce platform:
1. **Presentation Layer**: Web and mobile frontends
2. **API Layer**: Gateway with routing to microservices
3. **Data Layer**: Dedicated databases per service
The vertical flow clearly shows how requests travel from clients through the gateway to specific services and their databases.
## Usage Suggestions
- Include in architecture documentation
- Add to README for new developer onboarding
- Reference in technical design documents

View File

@@ -0,0 +1,66 @@
# Example: Before/After Diagram
## Scenario
A user asks: "Show the directory structure before and after our TypeScript migration."
## Generated Diagram
```
┌─────────────────────────────────────────────────────────────────────────┐
│ JAVASCRIPT TO TYPESCRIPT MIGRATION │
└─────────────────────────────────────────────────────────────────────────┘
BEFORE (JavaScript): AFTER (TypeScript):
src/ src/
├── components/ ├── components/
│ ├── Button.js ──► │ ├── Button.tsx ✓
│ ├── Button.css ──► │ │ (CSS modules imported)
│ ├── Form.js ──► │ ├── Form.tsx ✓
│ ├── Form.css ──► │ │ (CSS modules imported)
│ └── Modal.js ──► │ └── Modal.tsx ✓
├── utils/ ├── utils/
│ ├── helpers.js ──► │ ├── helpers.ts ✓
│ ├── constants.js ──► │ ├── constants.ts ✓
│ └── api.js ──► │ └── api.ts ✓
├── hooks/ ├── hooks/
│ ├── useAuth.js ──► │ ├── useAuth.ts ✓
│ └── useForm.js ──► │ └── useForm.ts ✓
├── types/ NEW ├── types/
│ │ ├── index.ts ✓
│ │ ├── api.d.ts ✓
│ │ └── components.d.ts ✓
├── App.js ──► ├── App.tsx ✓
├── index.js ──► ├── index.tsx ✓
└── .eslintrc.js ──► ├── .eslintrc.js (updated)
└── tsconfig.json NEW
Configuration Files:
├── package.json ──► ├── package.json (updated deps)
├── jest.config.js ──► ├── jest.config.js (ts-jest)
└── .babelrc ✗ └── (removed - using tsc)
Legend:
✓ = Conversion complete
──► = Transformed/updated
✗ = Removed
NEW = New file/directory
```
## Explanation
This before/after diagram shows the complete scope of a TypeScript migration:
- **File transformations**: .js → .tsx/.ts conversions
- **New additions**: types/ directory with type definitions
- **Removed files**: Babel config (replaced by TypeScript compiler)
- **Updated configs**: ESLint and Jest configurations
The parallel columns make it easy to trace each file's transformation.
## Usage Suggestions
- Include in migration PR description
- Add to project README as migration record
- Reference in team communication about changes

View File

@@ -0,0 +1,119 @@
# Example: Data Flow Diagram
## Scenario
A user asks: "Illustrate how user authentication data flows through our system."
## Generated Diagram
```
┌─────────────────────────────────────────────────────────────────────────┐
│ USER AUTHENTICATION FLOW │
└─────────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ Browser │
│ Login Form │
└──────────────┘
│ 1. POST /auth/login
│ { email, password }
┌──────────────┐
│ API Gateway │
│ (Express) │
└──────────────┘
│ 2. Route to auth service
┌──────────────────────────────────────────────────────────────┐
│ AUTH SERVICE │
├──────────────────────────────────────────────────────────────┤
│ │
│ 3. Validate credentials │
│ ┌─────────────┐ │
│ │ Hash pwd │──► Compare with stored hash │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ 4. Query user database │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Users DB │────►│ User record │ │
│ │ (Postgres) │ │ + roles │ │
│ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ 5. Generate tokens │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ JWT Access │ │ Refresh │ │
│ │ (15 min) │ │ (7 days) │ │
│ └─────────────┘ └─────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ 6. Store refresh token │
│ │ ┌─────────────┐ │
│ │ │ Redis │ │
│ │ │ Sessions │ │
│ │ └─────────────┘ │
│ │ │
└────────────┼──────────────────────────────────────────────────┘
│ 7. Return tokens
┌──────────────┐
│ API Gateway │
└──────────────┘
│ 8. Set cookies & respond
│ { accessToken, user }
┌──────────────┐
│ Browser │
│ Store JWT │
└──────────────┘
│ 9. Subsequent requests
│ Authorization: Bearer <token>
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ API Gateway │────►│ Middleware │────►│ Protected │
│ │ │ Verify JWT │ │ Resources │
└──────────────┘ └──────────────┘ └──────────────┘
TOKEN REFRESH FLOW:
Access Token Expired
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Browser │────►│ POST /auth/ │────►│ Redis │
│ Refresh Req │ │ refresh │ │ Validate │
└──────────────┘ └──────────────┘ └──────────────┘
│ │
│◄───────────────────┘
│ Valid? Issue new tokens
┌──────────────┐
│ New Access │
│ Token │
└──────────────┘
```
## Explanation
This data flow diagram shows the complete authentication lifecycle:
1. **Initial login flow**: Steps 1-8 show credential validation and token generation
2. **Token storage**: Redis for refresh tokens, browser for access tokens
3. **Protected resource access**: JWT verification middleware
4. **Token refresh**: Separate flow for getting new access tokens
The nested structure within the Auth Service box shows internal processing details while maintaining flow clarity.
## Usage Suggestions
- Include in security documentation
- Add to API documentation for developers
- Reference during security audits
- Share with new team members during onboarding

View File

@@ -0,0 +1,93 @@
# Example: Phased Migration Diagram
## Scenario
A user asks: "Create a diagram showing our database migration phases with current progress."
## Generated Diagram
```
┌─────────────────────────────────────────────────────────────────────────┐
│ DATABASE MIGRATION: MONGODB TO POSTGRESQL │
│ Target: Q4 2025 Completion │
└─────────────────────────────────────────────────────────────────────────┘
PHASE 1: Schema Design & Setup ✓
┌─────────────────────────────────────────────────────────────────────────┐
│ Status: COMPLETE Duration: 2w │
├─────────────────────────────────────────────────────────────────────────┤
│ ✓ Analyze MongoDB collections and relationships │
│ ✓ Design PostgreSQL schema with proper normalization │
│ ✓ Create migration scripts and rollback procedures │
│ ✓ Set up staging environment with both databases │
└─────────────────────────────────────────────────────────────────────────┘
PHASE 2: Dual-Write Implementation ✓
┌─────────────────────────────────────────────────────────────────────────┐
│ Status: COMPLETE Duration: 3w │
├─────────────────────────────────────────────────────────────────────────┤
│ ✓ Implement write-through to both MongoDB and PostgreSQL │
│ ✓ Add feature flags for gradual rollout │
│ ✓ Deploy to staging and validate data consistency │
│ ✓ Monitor for performance impact (< 50ms added latency) │
└─────────────────────────────────────────────────────────────────────────┘
PHASE 3: Historical Data Migration ⏳
┌─────────────────────────────────────────────────────────────────────────┐
│ Status: IN PROGRESS (60%) Duration: 4w │
├─────────────────────────────────────────────────────────────────────────┤
│ ✓ Migrate users collection (2.3M records) │
│ ✓ Migrate products collection (150K records) │
│ ⏳ Migrate orders collection (5.2M records) - 60% complete │
│ Migrate reviews collection (890K records) │
│ Validate data integrity across all tables │
└─────────────────────────────────────────────────────────────────────────┘
PHASE 4: Read Path Migration
┌─────────────────────────────────────────────────────────────────────────┐
│ Status: PENDING Duration: 2w │
├─────────────────────────────────────────────────────────────────────────┤
│ Switch read operations to PostgreSQL (feature flag) │
│ Run parallel queries and compare results │
│ Gradually increase PostgreSQL read traffic (10% → 100%) │
│ Monitor query performance and optimize indexes │
└─────────────────────────────────────────────────────────────────────────┘
PHASE 5: Cutover & Cleanup
┌─────────────────────────────────────────────────────────────────────────┐
│ Status: PENDING Duration: 1w │
├─────────────────────────────────────────────────────────────────────────┤
│ Disable MongoDB writes │
│ Update all application configuration │
│ Archive MongoDB data │
│ Remove dual-write code and feature flags │
│ Document lessons learned │
└─────────────────────────────────────────────────────────────────────────┘
Summary: Phase 3 of 5 │ Overall Progress: ~55% │ On Track for Q4
Legend:
✓ = Complete ⏳ = In Progress (blank) = Pending
```
## Explanation
This phased migration diagram provides:
- **Clear progress visibility**: Status and completion percentage per phase
- **Detailed tasks**: Specific actions within each phase
- **Time estimates**: Duration for planning purposes
- **Overall summary**: Quick status check at the bottom
The vertical flow shows dependencies between phases while the detailed boxes provide actionable information.
## Usage Suggestions
- Include in weekly status updates
- Add to project management tools
- Share with stakeholders for progress visibility
- Update after each milestone completion