Initial project foundation: Microservices architecture planning
- Created CLAUDE.md with architecture guidelines and context recovery guide - Created docs/PLAN.md with progressive implementation strategy - Created docs/PROGRESS.md for checkpoint tracking - Added .gitignore for Python, Node, Docker environments - Established API Gateway pattern with Console as orchestrator 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
jungwoo choi
67
.gitignore
vendored
Normal file
67
.gitignore
vendored
Normal file
@ -0,0 +1,67 @@
|
|||||||
|
# Python
|
||||||
|
__pycache__/
|
||||||
|
*.py[cod]
|
||||||
|
*$py.class
|
||||||
|
*.so
|
||||||
|
.Python
|
||||||
|
env/
|
||||||
|
venv/
|
||||||
|
.venv
|
||||||
|
pip-log.txt
|
||||||
|
pip-delete-this-directory.txt
|
||||||
|
.pytest_cache/
|
||||||
|
*.egg-info/
|
||||||
|
dist/
|
||||||
|
build/
|
||||||
|
|
||||||
|
# Node
|
||||||
|
node_modules/
|
||||||
|
npm-debug.log*
|
||||||
|
yarn-debug.log*
|
||||||
|
yarn-error.log*
|
||||||
|
.pnpm-debug.log*
|
||||||
|
dist/
|
||||||
|
build/
|
||||||
|
|
||||||
|
# Environment
|
||||||
|
.env
|
||||||
|
.env.local
|
||||||
|
.env.*.local
|
||||||
|
*.local
|
||||||
|
|
||||||
|
# IDE
|
||||||
|
.vscode/
|
||||||
|
.idea/
|
||||||
|
*.swp
|
||||||
|
*.swo
|
||||||
|
*~
|
||||||
|
.DS_Store
|
||||||
|
|
||||||
|
# Docker
|
||||||
|
*.log
|
||||||
|
docker-compose.override.yml
|
||||||
|
|
||||||
|
# Database
|
||||||
|
data/
|
||||||
|
*.db
|
||||||
|
*.sqlite
|
||||||
|
|
||||||
|
# Testing
|
||||||
|
coverage/
|
||||||
|
.coverage
|
||||||
|
htmlcov/
|
||||||
|
.tox/
|
||||||
|
.hypothesis/
|
||||||
|
|
||||||
|
# Temporary
|
||||||
|
tmp/
|
||||||
|
temp/
|
||||||
|
*.tmp
|
||||||
|
*.temp
|
||||||
|
*.bak
|
||||||
|
|
||||||
|
# Secrets
|
||||||
|
*.pem
|
||||||
|
*.key
|
||||||
|
*.crt
|
||||||
|
secrets/
|
||||||
269
CLAUDE.md
Normal file
269
CLAUDE.md
Normal file
@ -0,0 +1,269 @@
|
|||||||
|
# CLAUDE.md
|
||||||
|
|
||||||
|
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
|
||||||
|
|
||||||
|
## File Naming Convention
|
||||||
|
**IMPORTANT**: 모든 문서 파일은 대문자.md 형식으로 생성
|
||||||
|
- 예: README.md, CHANGELOG.md, TODO.md, ARCHITECTURE.md
|
||||||
|
|
||||||
|
## Context Recovery Guide
|
||||||
|
**IMPORTANT**: 새 세션 시작 시 반드시 확인할 파일들:
|
||||||
|
1. `docs/PROGRESS.md` - 현재 진행 상황과 다음 단계
|
||||||
|
2. `docs/PLAN.md` - 전체 구현 계획
|
||||||
|
3. `docker ps` - 실행 중인 서비스 확인
|
||||||
|
|
||||||
|
## Quick Status Check
|
||||||
|
```bash
|
||||||
|
# 진행 상황 빠른 확인
|
||||||
|
cat docs/PROGRESS.md | grep "Next Action"
|
||||||
|
```
|
||||||
|
|
||||||
|
## System Architecture
|
||||||
|
|
||||||
|
### Architecture Pattern: Microservices with Central Console
|
||||||
|
|
||||||
|
**Core Concept**: Console acts as the orchestrator and dashboard, while individual microservices handle domain-specific logic.
|
||||||
|
|
||||||
|
### Architecture Approaches
|
||||||
|
|
||||||
|
#### 1. API Gateway Pattern (Recommended)
|
||||||
|
Console serves as an API Gateway that:
|
||||||
|
- Routes requests to appropriate microservices
|
||||||
|
- Handles authentication/authorization centrally
|
||||||
|
- Aggregates responses from multiple services
|
||||||
|
- Provides service discovery and health monitoring
|
||||||
|
|
||||||
|
#### 2. Service Mesh Pattern
|
||||||
|
- Each service communicates directly via service mesh (Istio/Linkerd)
|
||||||
|
- Console focuses on monitoring and management
|
||||||
|
- Better for complex inter-service communication
|
||||||
|
|
||||||
|
#### 3. Event-Driven Architecture
|
||||||
|
- Services communicate via message broker (RabbitMQ/Kafka)
|
||||||
|
- Console subscribes to events for real-time monitoring
|
||||||
|
- Loose coupling between services
|
||||||
|
|
||||||
|
### Technology Stack
|
||||||
|
- **Backend**: FastAPI (Python 3.11) + Motor (MongoDB async driver)
|
||||||
|
- **Frontend**: React 18 + Vite + TypeScript + Material-UI v7
|
||||||
|
- **Database**: MongoDB 7.0
|
||||||
|
- **Cache**: Redis 7
|
||||||
|
- **Reverse Proxy**: Nginx
|
||||||
|
- **Container**: Docker & Docker Compose
|
||||||
|
- **Version Control**: git
|
||||||
|
- **API Documentation**: OpenAPI/Swagger
|
||||||
|
- **Service Communication**: REST + gRPC (for internal services)
|
||||||
|
|
||||||
|
### Service Configuration
|
||||||
|
- **Nginx**: Port 80 (reverse proxy)
|
||||||
|
- **Console Backend**: Port 8000 (API Gateway)
|
||||||
|
- **Console Frontend**: Port 3000
|
||||||
|
- **Services**:
|
||||||
|
- Images: 8001-8002
|
||||||
|
- OAuth: 8003-8004
|
||||||
|
- Applications: 8005-8006
|
||||||
|
- Users: 8007-8008
|
||||||
|
- Data: 8009-8010
|
||||||
|
- Statistics: 8011-8012
|
||||||
|
- **MongoDB**: Port 27017 (internal)
|
||||||
|
- **Redis**: Port 6379 (internal)
|
||||||
|
|
||||||
|
## Microservices Implementation Strategy
|
||||||
|
|
||||||
|
### Console as API Gateway (Recommended Approach)
|
||||||
|
|
||||||
|
#### Responsibilities
|
||||||
|
**Console Backend**:
|
||||||
|
- Service discovery and routing
|
||||||
|
- Authentication & authorization (JWT/OAuth2)
|
||||||
|
- Request/response transformation
|
||||||
|
- Rate limiting & throttling
|
||||||
|
- Circuit breaking for fault tolerance
|
||||||
|
- Centralized logging & monitoring
|
||||||
|
- API composition for complex operations
|
||||||
|
|
||||||
|
**Individual Microservices**:
|
||||||
|
- Domain-specific business logic
|
||||||
|
- Own database/collection management
|
||||||
|
- Event publishing for async operations
|
||||||
|
- Health endpoints for monitoring
|
||||||
|
- OpenAPI documentation
|
||||||
|
|
||||||
|
### Service Communication Patterns
|
||||||
|
|
||||||
|
#### 1. Synchronous Communication (REST)
|
||||||
|
```python
|
||||||
|
# Console backend routing example
|
||||||
|
@app.get("/api/users/{user_id}")
|
||||||
|
async def get_user(user_id: str):
|
||||||
|
# Route to users service
|
||||||
|
response = await http_client.get(f"http://users-service:8007/users/{user_id}")
|
||||||
|
return response.json()
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. Asynchronous Communication (Event-driven)
|
||||||
|
```python
|
||||||
|
# Service publishes event
|
||||||
|
await redis_client.publish("user.created", user_data)
|
||||||
|
|
||||||
|
# Console subscribes to events
|
||||||
|
async def handle_user_created(data):
|
||||||
|
# Update dashboard metrics
|
||||||
|
await update_statistics(data)
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3. Service Registry Pattern
|
||||||
|
```yaml
|
||||||
|
# services-registry.yaml
|
||||||
|
services:
|
||||||
|
users:
|
||||||
|
backend: "http://users-backend:8007"
|
||||||
|
frontend: "http://users-frontend:8008"
|
||||||
|
health: "/health"
|
||||||
|
oauth:
|
||||||
|
backend: "http://oauth-backend:8003"
|
||||||
|
frontend: "http://oauth-frontend:8004"
|
||||||
|
health: "/health"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Development Workflow
|
||||||
|
|
||||||
|
#### Commands
|
||||||
|
```bash
|
||||||
|
# Start all services
|
||||||
|
docker-compose up -d
|
||||||
|
|
||||||
|
# Start specific service
|
||||||
|
docker-compose up -d console users
|
||||||
|
|
||||||
|
# View logs
|
||||||
|
docker-compose logs -f [service-name]
|
||||||
|
|
||||||
|
# Rebuild service
|
||||||
|
docker-compose build [service-name]
|
||||||
|
docker-compose up -d [service-name]
|
||||||
|
|
||||||
|
# Run tests
|
||||||
|
docker-compose exec [service-name] pytest
|
||||||
|
|
||||||
|
# Database migrations
|
||||||
|
docker-compose exec [service-name] alembic upgrade head
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Service Development Guidelines
|
||||||
|
1. Each service should be independently deployable
|
||||||
|
2. Services share nothing except API contracts
|
||||||
|
3. Use correlation IDs for distributed tracing
|
||||||
|
4. Implement health checks and readiness probes
|
||||||
|
5. Version APIs appropriately (e.g., /api/v1/)
|
||||||
|
|
||||||
|
## Project Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
site11/
|
||||||
|
├── docker-compose.yml
|
||||||
|
├── nginx/
|
||||||
|
│ └── nginx.conf
|
||||||
|
├── console/
|
||||||
|
│ ├── backend/
|
||||||
|
│ │ ├── Dockerfile
|
||||||
|
│ │ └── requirements.txt
|
||||||
|
│ └── frontend/
|
||||||
|
│ ├── Dockerfile
|
||||||
|
│ ├── package.json
|
||||||
|
│ ├── vite.config.ts
|
||||||
|
│ ├── tsconfig.json
|
||||||
|
│ └── src/
|
||||||
|
│ ├── App.tsx
|
||||||
|
│ ├── main.tsx
|
||||||
|
│ ├── layouts/
|
||||||
|
│ │ └── AdminLayout.tsx
|
||||||
|
│ └── pages/
|
||||||
|
│ ├── Login.tsx
|
||||||
|
│ └── Register.tsx
|
||||||
|
├── services/
|
||||||
|
│ ├── images/
|
||||||
|
│ │ ├── backend/
|
||||||
|
│ │ └── frontend/
|
||||||
|
│ ├── oatuh/
|
||||||
|
│ │ ├── backend/
|
||||||
|
│ │ └── frontend/
|
||||||
|
│ ├── applications/
|
||||||
|
│ │ ├── backend/
|
||||||
|
│ │ └── frontend/
|
||||||
|
│ ├── users/
|
||||||
|
│ │ ├── backend/
|
||||||
|
│ │ └── frontend/
|
||||||
|
│ ├── data/
|
||||||
|
│ │ ├── backend/
|
||||||
|
│ │ └── frontend/
|
||||||
|
│ └── statistics/
|
||||||
|
│ ├── backend/
|
||||||
|
│ └── frontend/
|
||||||
|
├── docs/
|
||||||
|
│ └── PLAN.md
|
||||||
|
└── CLAUDE.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Service-Specific Architecture
|
||||||
|
|
||||||
|
### Console Service
|
||||||
|
- **Purpose**: Central orchestrator and dashboard
|
||||||
|
- **Key Features**:
|
||||||
|
- Service health monitoring dashboard
|
||||||
|
- Unified authentication portal
|
||||||
|
- API Gateway for all services
|
||||||
|
- Real-time metrics aggregation
|
||||||
|
- Service configuration management
|
||||||
|
|
||||||
|
### Microservice Template
|
||||||
|
Each service follows this structure:
|
||||||
|
```
|
||||||
|
service-name/
|
||||||
|
├── backend/
|
||||||
|
│ ├── Dockerfile
|
||||||
|
│ ├── requirements.txt
|
||||||
|
│ ├── app/
|
||||||
|
│ │ ├── main.py # FastAPI app
|
||||||
|
│ │ ├── models.py # Pydantic models
|
||||||
|
│ │ ├── routes.py # API endpoints
|
||||||
|
│ │ ├── database.py # MongoDB connection
|
||||||
|
│ │ └── services.py # Business logic
|
||||||
|
│ └── tests/
|
||||||
|
└── frontend/
|
||||||
|
├── Dockerfile
|
||||||
|
├── package.json
|
||||||
|
└── src/
|
||||||
|
├── api/ # Service API client
|
||||||
|
├── components/ # React components
|
||||||
|
└── hooks/ # Custom hooks
|
||||||
|
```
|
||||||
|
|
||||||
|
## Inter-Service Communication
|
||||||
|
|
||||||
|
### API Gateway Routes (Console)
|
||||||
|
```python
|
||||||
|
# Console backend routing configuration
|
||||||
|
SERVICES = {
|
||||||
|
"users": {"url": "http://users-backend:8007", "prefix": "/api/users"},
|
||||||
|
"oauth": {"url": "http://oauth-backend:8003", "prefix": "/api/auth"},
|
||||||
|
"images": {"url": "http://images-backend:8001", "prefix": "/api/images"},
|
||||||
|
"applications": {"url": "http://apps-backend:8005", "prefix": "/api/apps"},
|
||||||
|
"data": {"url": "http://data-backend:8009", "prefix": "/api/data"},
|
||||||
|
"statistics": {"url": "http://stats-backend:8011", "prefix": "/api/stats"}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Service Discovery
|
||||||
|
Services register themselves with Console on startup and send periodic heartbeats.
|
||||||
|
|
||||||
|
## Database Strategy
|
||||||
|
- **Shared MongoDB instance** with separate databases per service
|
||||||
|
- **Redis** for caching and pub/sub messaging
|
||||||
|
- Each service owns its data and exposes it via APIs
|
||||||
|
|
||||||
|
## Security Considerations
|
||||||
|
- JWT tokens issued by OAuth service
|
||||||
|
- Console validates tokens and forwards to services
|
||||||
|
- Internal service communication uses service tokens
|
||||||
|
- Rate limiting at API Gateway level
|
||||||
401
docs/PLAN.md
Normal file
401
docs/PLAN.md
Normal file
@ -0,0 +1,401 @@
|
|||||||
|
# Microservices Architecture Implementation Plan
|
||||||
|
|
||||||
|
## Project Overview
|
||||||
|
Build a microservices-based platform with a central Console service acting as an orchestrator and API Gateway, managing multiple domain-specific services.
|
||||||
|
|
||||||
|
## Architecture Decision
|
||||||
|
**Selected Pattern**: API Gateway Pattern with Console as the central orchestrator
|
||||||
|
- Console handles authentication, routing, and monitoring
|
||||||
|
- Each microservice focuses on domain-specific logic
|
||||||
|
- Services communicate via REST APIs and Redis pub/sub
|
||||||
|
|
||||||
|
## Progressive Implementation Strategy
|
||||||
|
|
||||||
|
### Step-by-Step Approach
|
||||||
|
큰 그림을 먼저 구성하고, 핵심 기능부터 점진적으로 확장하는 전략
|
||||||
|
|
||||||
|
## Implementation Phases
|
||||||
|
|
||||||
|
### Step 1: Minimal Foundation (Day 1-2)
|
||||||
|
**목표**: 가장 기본적인 구조 확립
|
||||||
|
```
|
||||||
|
site11/
|
||||||
|
├── docker-compose.yml # 최소 구성 (Console만)
|
||||||
|
├── console/
|
||||||
|
│ └── backend/
|
||||||
|
│ └── main.py # Hello World API
|
||||||
|
└── README.md
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] 간단한 docker-compose.yml 생성
|
||||||
|
- [ ] Console FastAPI "Hello World"
|
||||||
|
- [ ] 기본 health check endpoint
|
||||||
|
- [ ] Docker로 실행 확인
|
||||||
|
|
||||||
|
### Step 2: Add First Service (Day 3-4)
|
||||||
|
**목표**: Console과 하나의 서비스 연결
|
||||||
|
```
|
||||||
|
site11/
|
||||||
|
├── docker-compose.yml
|
||||||
|
├── console/
|
||||||
|
│ └── backend/
|
||||||
|
│ └── main.py # Gateway 역할 추가
|
||||||
|
└── services/
|
||||||
|
└── users/
|
||||||
|
└── backend/
|
||||||
|
└── main.py # Users 서비스
|
||||||
|
```
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] Users 서비스 생성
|
||||||
|
- [ ] Console에서 Users로 라우팅
|
||||||
|
- [ ] 서비스 간 통신 테스트
|
||||||
|
- [ ] 간단한 CRUD API
|
||||||
|
|
||||||
|
### Step 3: Database Integration (Day 5-6)
|
||||||
|
**목표**: MongoDB 연결 및 기본 데이터 저장
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] MongoDB 컨테이너 추가
|
||||||
|
- [ ] Console과 Users 서비스 DB 연결
|
||||||
|
- [ ] 기본 데이터 모델 생성
|
||||||
|
- [ ] 실제 데이터 CRUD 테스트
|
||||||
|
|
||||||
|
### Step 4: Frontend Skeleton (Week 2)
|
||||||
|
**목표**: 최소한의 UI 구성
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] Console Frontend 생성 (React + Vite)
|
||||||
|
- [ ] 기본 레이아웃
|
||||||
|
- [ ] 서비스 상태 표시
|
||||||
|
- [ ] Nginx 설정
|
||||||
|
|
||||||
|
### Step 5: Authentication Basic (Week 2)
|
||||||
|
**목표**: 간단한 인증 시스템
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] JWT 토큰 생성
|
||||||
|
- [ ] Login endpoint
|
||||||
|
- [ ] Token 검증 미들웨어
|
||||||
|
- [ ] Protected routes
|
||||||
|
|
||||||
|
### Step 6: Second Service (Week 3)
|
||||||
|
**목표**: 두 번째 서비스 추가로 패턴 확립
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] OAuth 또는 Images 서비스 추가
|
||||||
|
- [ ] Console 라우팅 확장
|
||||||
|
- [ ] 서비스 간 통신 패턴 확립
|
||||||
|
- [ ] Service registry 기초
|
||||||
|
|
||||||
|
### Step 7: Service Communication (Week 3)
|
||||||
|
**목표**: 서비스 간 통신 패턴 구현
|
||||||
|
|
||||||
|
**Tasks**:
|
||||||
|
- [ ] Redis pub/sub 설정
|
||||||
|
- [ ] Event 기반 통신 예제
|
||||||
|
- [ ] Service discovery 구현
|
||||||
|
- [ ] Health check 자동화
|
||||||
|
|
||||||
|
### Step 8: Gradual Service Addition (Week 4-5)
|
||||||
|
**목표**: 나머지 서비스 점진적 추가
|
||||||
|
|
||||||
|
**각 서비스별로**:
|
||||||
|
- [ ] 기본 구조 생성
|
||||||
|
- [ ] Console 연결
|
||||||
|
- [ ] 핵심 API 구현
|
||||||
|
- [ ] Frontend 컴포넌트 추가
|
||||||
|
|
||||||
|
## 현재 시작점 (NOW)
|
||||||
|
|
||||||
|
### 즉시 시작할 수 있는 첫 걸음
|
||||||
|
|
||||||
|
#### 1. 최소 Docker 환경 구성
|
||||||
|
```bash
|
||||||
|
# 실행 명령
|
||||||
|
docker-compose up -d console
|
||||||
|
curl http://localhost:8000/health
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. Console 서비스만으로 시작
|
||||||
|
- Health endpoint
|
||||||
|
- 간단한 API Gateway 구조
|
||||||
|
- 서비스 등록 준비
|
||||||
|
|
||||||
|
#### 3. 하나씩 추가하며 테스트
|
||||||
|
- Users 서비스 하나만 추가
|
||||||
|
- 통신 확인
|
||||||
|
- 패턴 확립 후 확장
|
||||||
|
|
||||||
|
### 핵심 원칙
|
||||||
|
1. **작동하는 코드 우선** - 완벽한 설계보다 동작하는 MVP
|
||||||
|
2. **점진적 복잡도** - 간단한 것부터 시작해서 기능 추가
|
||||||
|
3. **빠른 피드백** - 각 단계마다 실행하고 확인
|
||||||
|
4. **패턴 확립** - 첫 서비스로 패턴을 만들고 복제
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 상세 구현 계획 (참고용)
|
||||||
|
|
||||||
|
### Phase 1: Foundation Setup (Week 1)
|
||||||
|
#### Goals
|
||||||
|
- Set up project structure
|
||||||
|
- Configure Docker environment
|
||||||
|
- Establish basic infrastructure
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] Initialize Git repository
|
||||||
|
- [ ] Create Docker Compose configuration
|
||||||
|
- [ ] Set up Nginx reverse proxy
|
||||||
|
- [ ] Configure MongoDB and Redis containers
|
||||||
|
- [ ] Create base directory structure for all services
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- Working Docker environment
|
||||||
|
- Basic networking between containers
|
||||||
|
- Database and cache ready
|
||||||
|
|
||||||
|
### Phase 2: Console Service - Core (Week 2)
|
||||||
|
#### Goals
|
||||||
|
- Implement Console as API Gateway
|
||||||
|
- Set up authentication system
|
||||||
|
- Create service registry
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] Console Backend
|
||||||
|
- [ ] FastAPI application setup
|
||||||
|
- [ ] JWT authentication implementation
|
||||||
|
- [ ] Service registry and discovery
|
||||||
|
- [ ] API routing mechanism
|
||||||
|
- [ ] Health check endpoints
|
||||||
|
- [ ] Console Frontend
|
||||||
|
- [ ] React + Vite setup
|
||||||
|
- [ ] Login/Register pages
|
||||||
|
- [ ] Admin dashboard layout
|
||||||
|
- [ ] Service status dashboard
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- Working authentication system
|
||||||
|
- Basic API Gateway functionality
|
||||||
|
- Service health monitoring dashboard
|
||||||
|
|
||||||
|
### Phase 3: OAuth Service (Week 3)
|
||||||
|
#### Goals
|
||||||
|
- Centralized authentication service
|
||||||
|
- OAuth2 implementation
|
||||||
|
- User session management
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] OAuth Backend
|
||||||
|
- [ ] OAuth2 server implementation
|
||||||
|
- [ ] Token generation and validation
|
||||||
|
- [ ] User authentication endpoints
|
||||||
|
- [ ] Integration with Console
|
||||||
|
- [ ] OAuth Frontend
|
||||||
|
- [ ] OAuth consent screens
|
||||||
|
- [ ] Token management UI
|
||||||
|
- [ ] Application registration
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- OAuth2 server
|
||||||
|
- Token-based authentication
|
||||||
|
- Integration with Console
|
||||||
|
|
||||||
|
### Phase 4: Users Service (Week 4)
|
||||||
|
#### Goals
|
||||||
|
- User management microservice
|
||||||
|
- Profile management
|
||||||
|
- User data CRUD operations
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] Users Backend
|
||||||
|
- [ ] User model and database schema
|
||||||
|
- [ ] CRUD APIs for user management
|
||||||
|
- [ ] Profile management endpoints
|
||||||
|
- [ ] Integration with OAuth service
|
||||||
|
- [ ] Users Frontend
|
||||||
|
- [ ] User list and search
|
||||||
|
- [ ] Profile editing interface
|
||||||
|
- [ ] User details view
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- Complete user management system
|
||||||
|
- Profile management features
|
||||||
|
- Admin user interface
|
||||||
|
|
||||||
|
### Phase 5: Core Microservices (Weeks 5-6)
|
||||||
|
#### Goals
|
||||||
|
- Implement remaining core services
|
||||||
|
- Establish inter-service communication
|
||||||
|
|
||||||
|
#### Services to Implement
|
||||||
|
1. **Images Service**
|
||||||
|
- Image upload/download
|
||||||
|
- Image processing
|
||||||
|
- Storage management
|
||||||
|
|
||||||
|
2. **Applications Service**
|
||||||
|
- Application registration
|
||||||
|
- Configuration management
|
||||||
|
- Version control
|
||||||
|
|
||||||
|
3. **Data Service**
|
||||||
|
- Data import/export
|
||||||
|
- Data transformation
|
||||||
|
- API for data access
|
||||||
|
|
||||||
|
4. **Statistics Service**
|
||||||
|
- Metrics collection
|
||||||
|
- Analytics dashboard
|
||||||
|
- Report generation
|
||||||
|
|
||||||
|
#### Tasks per Service
|
||||||
|
- [ ] Backend implementation
|
||||||
|
- [ ] Domain models
|
||||||
|
- [ ] Business logic
|
||||||
|
- [ ] REST APIs
|
||||||
|
- [ ] Event publishing
|
||||||
|
- [ ] Frontend implementation
|
||||||
|
- [ ] Service-specific UI
|
||||||
|
- [ ] Integration with Console
|
||||||
|
- [ ] Dashboard widgets
|
||||||
|
|
||||||
|
### Phase 6: Integration & Testing (Week 7)
|
||||||
|
#### Goals
|
||||||
|
- End-to-end integration
|
||||||
|
- Performance optimization
|
||||||
|
- Security hardening
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] Integration Testing
|
||||||
|
- [ ] Service communication tests
|
||||||
|
- [ ] Load testing
|
||||||
|
- [ ] Security testing
|
||||||
|
- [ ] Optimization
|
||||||
|
- [ ] Redis caching implementation
|
||||||
|
- [ ] Database indexing
|
||||||
|
- [ ] API response optimization
|
||||||
|
- [ ] Documentation
|
||||||
|
- [ ] API documentation (OpenAPI)
|
||||||
|
- [ ] Deployment guide
|
||||||
|
- [ ] Developer documentation
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- Fully integrated system
|
||||||
|
- Performance benchmarks
|
||||||
|
- Complete documentation
|
||||||
|
|
||||||
|
### Phase 7: Monitoring & DevOps (Week 8)
|
||||||
|
#### Goals
|
||||||
|
- Production readiness
|
||||||
|
- Monitoring and alerting
|
||||||
|
- CI/CD pipeline
|
||||||
|
|
||||||
|
#### Tasks
|
||||||
|
- [ ] Monitoring Setup
|
||||||
|
- [ ] Prometheus metrics
|
||||||
|
- [ ] Grafana dashboards
|
||||||
|
- [ ] Log aggregation (ELK stack)
|
||||||
|
- [ ] DevOps
|
||||||
|
- [ ] GitHub Actions CI/CD
|
||||||
|
- [ ] Automated testing
|
||||||
|
- [ ] Docker image optimization
|
||||||
|
- [ ] Production Configuration
|
||||||
|
- [ ] Environment variables
|
||||||
|
- [ ] Secrets management
|
||||||
|
- [ ] Backup strategies
|
||||||
|
|
||||||
|
#### Deliverables
|
||||||
|
- Production-ready deployment
|
||||||
|
- Monitoring dashboards
|
||||||
|
- Automated deployment pipeline
|
||||||
|
|
||||||
|
## Technical Implementation Details
|
||||||
|
|
||||||
|
### Service Communication Flow
|
||||||
|
```
|
||||||
|
Client Request → Nginx → Console (API Gateway) → Microservice
|
||||||
|
↓
|
||||||
|
Authentication Check
|
||||||
|
↓
|
||||||
|
Request Routing
|
||||||
|
↓
|
||||||
|
Response Aggregation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Database Strategy
|
||||||
|
```
|
||||||
|
MongoDB Instance
|
||||||
|
├── console_db # Console service data
|
||||||
|
├── users_db # Users service data
|
||||||
|
├── oauth_db # OAuth tokens and sessions
|
||||||
|
├── images_db # Image metadata
|
||||||
|
├── applications_db # Application data
|
||||||
|
├── data_db # Generic data storage
|
||||||
|
└── statistics_db # Analytics data
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Versioning Strategy
|
||||||
|
- All APIs follow `/api/v1/` pattern
|
||||||
|
- Version in URL path for major versions
|
||||||
|
- Header-based versioning for minor updates
|
||||||
|
|
||||||
|
### Security Implementation
|
||||||
|
1. **Authentication Flow**
|
||||||
|
- User login → OAuth service
|
||||||
|
- OAuth service issues JWT
|
||||||
|
- Console validates JWT on each request
|
||||||
|
- Console forwards validated requests to services
|
||||||
|
|
||||||
|
2. **Service-to-Service Auth**
|
||||||
|
- Internal service tokens
|
||||||
|
- mTLS for production
|
||||||
|
- Network isolation via Docker networks
|
||||||
|
|
||||||
|
### Development Workflow
|
||||||
|
1. **Local Development**
|
||||||
|
```bash
|
||||||
|
docker-compose up -d [service-name]
|
||||||
|
docker-compose logs -f [service-name]
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Testing**
|
||||||
|
```bash
|
||||||
|
docker-compose exec [service-name] pytest
|
||||||
|
```
|
||||||
|
|
||||||
|
3. **Deployment**
|
||||||
|
```bash
|
||||||
|
docker-compose build
|
||||||
|
docker-compose up -d
|
||||||
|
```
|
||||||
|
|
||||||
|
## Success Criteria
|
||||||
|
- [ ] All services independently deployable
|
||||||
|
- [ ] Console successfully routes to all services
|
||||||
|
- [ ] Authentication works across all services
|
||||||
|
- [ ] Health monitoring shows all services green
|
||||||
|
- [ ] Load testing shows <100ms p95 latency
|
||||||
|
- [ ] Zero downtime deployments possible
|
||||||
|
|
||||||
|
## Risk Mitigation
|
||||||
|
1. **Service Failure**: Circuit breakers in Console
|
||||||
|
2. **Data Consistency**: Event sourcing for critical operations
|
||||||
|
3. **Performance**: Redis caching layer
|
||||||
|
4. **Security**: Regular security audits, dependency updates
|
||||||
|
|
||||||
|
## Timeline Summary
|
||||||
|
- **Week 1**: Foundation and infrastructure
|
||||||
|
- **Week 2**: Console core implementation
|
||||||
|
- **Week 3**: OAuth service
|
||||||
|
- **Week 4**: Users service
|
||||||
|
- **Weeks 5-6**: Remaining microservices
|
||||||
|
- **Week 7**: Integration and testing
|
||||||
|
- **Week 8**: Monitoring and production setup
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
1. Review and approve plan
|
||||||
|
2. Set up Git repository
|
||||||
|
3. Begin Phase 1 implementation
|
||||||
|
4. Schedule weekly progress reviews
|
||||||
113
docs/PROGRESS.md
Normal file
113
docs/PROGRESS.md
Normal file
@ -0,0 +1,113 @@
|
|||||||
|
# Progress Tracking & Context Management
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
이 파일은 Claude의 컨텍스트가 리셋되어도 빠르게 현재 진행 상황을 파악하고 이어서 작업할 수 있도록 돕는 체크포인트 문서입니다.
|
||||||
|
|
||||||
|
## Current Status
|
||||||
|
- **Date Started**: 2025-09-09
|
||||||
|
- **Current Phase**: Planning Complete
|
||||||
|
- **Next Action**: Step 1 - Minimal Foundation 구현
|
||||||
|
|
||||||
|
## Completed Checkpoints
|
||||||
|
✅ Project structure planning (CLAUDE.md)
|
||||||
|
✅ Implementation plan created (docs/PLAN.md)
|
||||||
|
✅ Progressive approach defined
|
||||||
|
|
||||||
|
## Active Working Files
|
||||||
|
```
|
||||||
|
현재 작업 중인 주요 파일:
|
||||||
|
- /docs/PLAN.md (구현 계획)
|
||||||
|
- /CLAUDE.md (아키텍처 가이드)
|
||||||
|
- /docs/PROGRESS.md (이 파일)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Next Immediate Steps
|
||||||
|
```bash
|
||||||
|
# 다음 작업 시작 명령
|
||||||
|
# Step 1: Create docker-compose.yml
|
||||||
|
# Step 2: Create console/backend/main.py
|
||||||
|
# Step 3: Test with docker-compose up
|
||||||
|
```
|
||||||
|
|
||||||
|
## Code Snippets Ready to Use
|
||||||
|
|
||||||
|
### 1. Minimal docker-compose.yml
|
||||||
|
```yaml
|
||||||
|
version: '3.8'
|
||||||
|
services:
|
||||||
|
console:
|
||||||
|
build: ./console/backend
|
||||||
|
ports:
|
||||||
|
- "8000:8000"
|
||||||
|
environment:
|
||||||
|
- ENV=development
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Console main.py starter
|
||||||
|
```python
|
||||||
|
from fastapi import FastAPI
|
||||||
|
app = FastAPI(title="Console API Gateway")
|
||||||
|
|
||||||
|
@app.get("/health")
|
||||||
|
async def health():
|
||||||
|
return {"status": "healthy", "service": "console"}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Important Decisions Made
|
||||||
|
1. **Architecture**: API Gateway Pattern with Console as orchestrator
|
||||||
|
2. **Tech Stack**: FastAPI + React + MongoDB + Redis + Docker
|
||||||
|
3. **Approach**: Progressive implementation (simple to complex)
|
||||||
|
4. **First Service**: Users service after Console
|
||||||
|
|
||||||
|
## Questions to Ask When Resuming
|
||||||
|
새로운 세션에서 이어서 작업할 때 확인할 사항:
|
||||||
|
1. "PROGRESS.md 파일을 확인했나요?"
|
||||||
|
2. "마지막으로 완료한 Step은 무엇인가요?"
|
||||||
|
3. "현재 에러나 블로킹 이슈가 있나요?"
|
||||||
|
|
||||||
|
## Git Commits Pattern
|
||||||
|
각 Step 완료 시 커밋 메시지:
|
||||||
|
```
|
||||||
|
Step X: [간단한 설명]
|
||||||
|
- 구현 내용 1
|
||||||
|
- 구현 내용 2
|
||||||
|
```
|
||||||
|
|
||||||
|
## Directory Structure Snapshot
|
||||||
|
```
|
||||||
|
site11/
|
||||||
|
├── CLAUDE.md ✅ Created
|
||||||
|
├── docs/
|
||||||
|
│ ├── PLAN.md ✅ Created
|
||||||
|
│ └── PROGRESS.md ✅ Created (this file)
|
||||||
|
├── console/ 🔄 Next
|
||||||
|
│ └── backend/
|
||||||
|
│ └── main.py
|
||||||
|
└── docker-compose.yml 🔄 Next
|
||||||
|
```
|
||||||
|
|
||||||
|
## Context Recovery Commands
|
||||||
|
새 세션에서 빠르게 상황 파악하기:
|
||||||
|
```bash
|
||||||
|
# 1. 현재 구조 확인
|
||||||
|
ls -la
|
||||||
|
|
||||||
|
# 2. 진행 상황 확인
|
||||||
|
cat docs/PROGRESS.md
|
||||||
|
|
||||||
|
# 3. 다음 단계 확인
|
||||||
|
grep "Step" docs/PLAN.md | head -5
|
||||||
|
|
||||||
|
# 4. 실행 중인 컨테이너 확인
|
||||||
|
docker ps
|
||||||
|
```
|
||||||
|
|
||||||
|
## Error Log
|
||||||
|
문제 발생 시 여기에 기록:
|
||||||
|
- (아직 없음)
|
||||||
|
|
||||||
|
## Notes for Next Session
|
||||||
|
- Step 1부터 시작
|
||||||
|
- docker-compose.yml 생성 필요
|
||||||
|
- console/backend/main.py 생성 필요
|
||||||
|
- 모든 문서 파일은 대문자.md 형식으로 생성 (예: README.md, SETUP.md)
|
||||||
Reference in New Issue
Block a user