How doocheol/chocoletter works
<explanation>
1. Identify the project type and purpose
- This is a full‑stack Valentine’s Day anonymous letter/gift service called Chocoletter.
- It consists of three codebases:
• chocoletter-client (React + TypeScript SPA)
• chocoletter-server (Spring Boot monolith exposing REST APIs, scheduler, OAuth, persistence)
• chocoletter-chat (Spring Boot chat microservice using WebSockets/STOMP and Kafka)
2. Top‑level architecture overview
- Draw three logical “boxes” for the three tiers:
A. Frontend (Browser)
B. Backend services (split into Main API & Chat microservice)
C. Datastores & Message broker
- Show deployment zones (per exec/build_deploy):
• Server 1: FE static hosting + OpenVidu signaling/turn
• Server 2: chocoletter-server
• Server 3: chocoletter-chat + Kafka cluster + MongoDB
3. Main components
a. Frontend (Client SPA)
- React/Vite app served from Nginx or CDNs on Server 1
- Interacts via HTTPS for REST (axios)
- Opens WebSocket (STOMP) to Chat microservice for real‑time messaging
- Invokes OpenVidu API (WebRTC) via a signaling endpoint on Server 1
- Uses Web Crypto for front‑end encryption of letter contents, Recoil for state
b. Main API (chocoletter‑server)
- Spring Boot monolith with layered MVC: Controllers → Services → Repositories (JPA/MySQL)
- Exposes REST endpoints for: authentication (OAuth2/Kakao), member, gift, letter, gift‑box, alarm, chatroom (not real‑time messaging, just metadata), unboxingRoom
- Scheduler for alarm jobs (AlarmScheduler)
- SecurityFilter chain: JWTAuthenticationFilter, time‑based access filter
- External integrations: Kakao OAuth2, OpenVidu REST (for session/token), Swagger UI
c. Chat microservice (chocoletter‑chat)
- Spring Boot app deployed on Server 3
- Exposes WebSocket endpoints (StompInterceptor + WebSocketConfig)
- Publishes incoming messages to Kafka topic via ChatMessageProducer
- Consumes from Kafka topic via ChatMessageConsumer and broadcasts to subscribed WebSocket sessions
- Persists chat history (if required) to MongoDB or in‑memory repository
- Configured by KafkaProducerConfig / KafkaConsumerConfig
d. Datastores & Broker
- MySQL for main data (members, gifts, letters, gift‑boxes, unboxing times, alarms)
- MongoDB for chat persistence
- Apache Kafka cluster for pub/sub between chat producer/consumer
e. Infra & CI/CD
- Docker images for each service, orchestrated via Docker Compose or Kubernetes
- Jenkins triggers builds, pushes to Docker registry, deploys to each server
- Portainer for container management, Datadog for monitoring
4. Relationships & data flows
1. User’s browser loads static assets from Server 1 → React SPA
2. SPA ‑‑HTTPS→ Main API for data operations
3. SPA ‑‑WSS→ Chat microservice for real‑time chat
4. Chat service ↔ Kafka broker (produce/consume)
5. Chat service ↔ MongoDB for message storage
6. Main API ↔ MySQL via JPA repositories
7. Main API ↔ OpenVidu server for video session creation
8. Main API ↔ Kakao OAuth2 external API for login
9. Jenkins ↔ Docker registry ↔ Servers for deploy
5. Architectural patterns & design principles
- Microservice for chat to isolate real‑time load and scale independently
- Monolithic API for core business logic with layered MVC & Spring idioms
- Event‑driven messaging (Kafka) to decouple producers/consumers
- REST‑over‑HTTP for CRUD, STOMP/WebSocket for real‑time
- Scheduler pattern (AlarmScheduler) for cron‑style tasks
- Use of filters/interceptors for cross‑cutting concerns (auth, ID decryption)
6. Diagram‐drawing guidelines
- Use rectangular boxes for each component group: FE, Main API, Chat Service, Datastores, External Services, CI/CD
- Color‐code by type (e.g., blue for frontend, green for backend, orange for infra, gray for external)
- Label each box clearly (e.g., “React SPA”, “Spring Boot API”, “Chat Microservice”)
- Use directional arrows:
• Solid arrows for request/response (SPA → API)
• Dashed arrows for async messaging (Chat → Kafka → Chat)
• Double‑headed arrows for bidirectional WebSocket flows
- Annotate arrows with protocols/tech (HTTPS/REST, WSS/STOMP, JDBC/JPA, Kafka Topic X, RPC (OpenVidu))
- Position Datastores along the bottom, connected to their services
- Place external services (Kakao OAuth, OpenVidu) off to one side
7. Tailoring tips
- Emphasize separation of concerns: UI vs. core API vs. real‑time chat
- Highlight scaling boundaries: chat service + Kafka cluster can be scaled out
- Show CI/CD pipeline triggering Docker builds & deployments to each server
- If presenting to ops, add network/security boundaries: DMZ, firewall rules, Nginx proxy
8. Required diagram elements
- Component boxes with names and icons/logos (React, Spring, Kafka, MySQL, MongoDB)
- Directional arrows with labels (REST, STOMP, WebSocket, JDBC, etc.)
- Color coding or shapes to distinguish:
• Frontend
• Backend services
• Data layer
• Message broker
• External integrations
• CI/CD tools
- Legend explaining colors/shapes
By following these steps and capturing each of these components and their interactions, you will produce a clear, detailed architecture diagram that reflects Chocoletter’s systems, deployment, and technology choices.