Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions week07/mission/mission.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
![image.png](attachment:27084a4a-1817-4b3c-bfc4-77e680ed9439:image.png)

![image.png](attachment:1db38a13-d835-4e5b-8fe2-f6cb584f1fa9:image.png)

![image.png](attachment:6c292aa5-8cf7-4b0f-9021-d6fbc282484a:image.png)

미들웨어가 무엇인가

Express에서 요청(req)과 응답(res) 사이에 끼워 넣는 함수들.

app.use((req, res, next) => { ...; next(); }) 형태로 등록하고, 순차적으로 실행되며 필요하면 응답을 끝내거나 next()로 다음 단계로 넘김.

공통 로깅, 인증, 파서(express.json), 쿠키 파서, 정적 파일 제공, 에러 처리 등을 각각 독립 함수로 두고 체인처럼 묶어두는 것임

- morgan: 요청 로그 미들웨어
- cookieParser: 쿠키를 req.cookies 로 파싱
- express.json, express.urlencoded: 바디 파싱 미들웨어
- 커스텀 404 핸들러와 errorHandler: 라우트 이후 실행되는 에러 처리 미들웨어

![image.png](attachment:b92a70fa-a400-4088-883d-7fc5d3ea8bce:image.png)

에러 미들웨어는 서버 라우팅 체인 맨 끝에 붙어서 모든 예외를 한 번에 처리하는 안전장치이이다. 먼저 AppError 계열인지 확인해서, 우리가 의도적으로 던진 에러라면 그대로 쓰고, 그렇지 않으면 new AppError 로 감싸서 메시지·상태코드를 표준 형태로 바꿔준다. 개발 모드에서는 원본 스택을 details 로 남기고 console.error 로 로그를 찍지만, 운영 모드에서는 메시지만 노출하도록 구분했다. 최종적으로 { success: false, code, message } 구조의 JSON을 내려주기 때문에, 컨트롤러 어디에서 오류가 나도 클라이언트는 동일한 실패 응답 포맷을 받을 수 있다.
52 changes: 52 additions & 0 deletions week08/keyword/keyword.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
- Swagger
- **API 설명서를 자동으로 만들어주는 도구**
- 백엔드에서 만든 API를 시각화해 문서처럼 보여줌
- Swagger UI를 통해 브라우저에서 API 목록, 파라미터, 응답 구조 등을 확인 가능
- 코드에 주석만 달아도 문서가 자동 생성됨
(`swagger-jsdoc`, `swagger-ui-express` 등 사용)
- 프론트엔드, 기획자, QA와 협업 시 커뮤니케이션 비용 절감
- API를 직접 테스트할 수 있는 UI 제공

**장점**

- 문서 자동 생성 → 유지보수 편함
- UI로 한눈에 확인 가능
- 팀 협업에 최적화

**단점**

- OpenAPI 3.1 완전 지원 부족
- 복잡한 커스터마이징 어려움
- OpenAPI
- **REST API 명세를 위한 표준 포맷 (YAML 또는 JSON)**
- Swagger는 이 OpenAPI 명세를 읽고 문서를 생성함
→ OpenAPI는 “언어”, Swagger는 “뷰어” 역할
- `paths`, `parameters`, `requestBody`, `responses` 등 구조화된 형태로 API를 정의함
- 도구와 언어 상관없이 동일한 규칙으로 API를 문서화 가능

**장점**

- 문서 표준화
- 다양한 툴과 연동 쉬움
- Git 등으로 버전 관리 가능

**단점**

- 문법이 복잡하게 느껴질 수 있음
- 작성 규칙에 익숙해지는데 시간 필요
- OpenAPI Component
- **OpenAPI 문서에서 공통되는 항목을 재사용 가능하게 묶어둔 곳**
- 중복된 객체(예: `User`, `ErrorResponse`)를 하나만 정의하고 참조 가능
- 유지보수 편리, 문서 가독성 향상

```yaml
components:
schemas:
User:
type: object
properties:
id:
type: integer
name:
type: string
```
5 changes: 5 additions & 0 deletions week08/mission/mission.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
https://github.com/sojung0628/UMC_node_mission

![image.png](attachment:144a9ac7-6e91-4216-a79f-08a66ccc4d84:image.png)

![image.png](attachment:d3806539-9630-49a8-99ea-f5d472a1164f:image.png)