req, res가 앱으로 들어온다.
요청은 등록된 순서의 스택을 통과하고, 응답이나 오류가 흐름을 바꾼다
Express 앱은 하나의 큰 함수처럼 동작한다. Node HTTP 서버가 만든
req, res를 받아 app.use,
라우터, 핸들러, 에러 미들웨어를 등록 순서대로 검사하고, 각 단계는
next(), 응답 전송, next(err) 중 하나로
다음 방향을 결정한다.
정상 경로는 next()로 전진하고, 오류 경로는 에러
핸들러로 점프한다
request -> layer match -> handler -> response | next(err)
app.use()
logging, auth, parser가 앞에서 요청을 다듬는다.
res.json()처럼 응답을 만들거나 다음으로 넘긴다.
정상 요청 lane
next() 또는 response
req, res가 Express 앱으로 들어온다.
로그, CORS, 쿠키, 세션, JSON 파서가 앞에서 요청을 다듬는다.
mount path, method, path가 맞으면 업무 핸들러가 실행된다.
res.json() 같은 응답이 나가면 같은 요청은 끝난다.
오류 lane
next(err)
next(err)나 비동기 오류가 일반 흐름을 끊는다.
(err, req, res, next) 시그니처만 오류를 받는다.
응답하지 않은 정상 요청은 마지막 404 처리로 떨어진다.
app.use(fn)
모든 요청 또는 지정 path prefix
등록한 위치보다 뒤의 레이어에만 영향을 준다.
body parsing, auth, logging, static, rate limit을 둔다.
next() 또는 응답
계속 진행하려면 반드시 다음으로 넘긴다.
next()도 응답도 없으면 요청이 매달린다.
router.use()
mount path 안의 Router 레이어
Router는 자체 미들웨어와 라우트를 가진 독립 스택이다.
관리자 인증, API 버전, 특정 리소스 검증을 묶는다.
내부에서 끝나지 않으면 다음 app 레이어로 돌아간다.
catch-all보다 늦게 붙이면 라우터가 실행되지 않는다.
app.get/post()
HTTP method와 path가 둘 다 맞을 때
입력 검증, 서비스 호출, DB 접근, 응답 포맷을 담당한다.
res.json, res.render, redirect, status
code를 결정한다.
응답을 보냈다면 일반적으로 다음 핸들러로 넘기지 않는다.
비동기 분기에서 응답을 두 번 보내면 headers 오류가 난다.
app.use((err,...))
인자가 4개인 에러 처리 미들웨어
next(err), throw를 잡아 넘긴 비동기 오류가 들어온다.
로그, status, 사용자용 메시지, JSON 오류 형식을 통일한다.
라우트 뒤에 있어야 앞에서 생긴 오류를 받는다.
응답이 시작된 뒤 오류가 나면 별도 처리나 연결 종료가 필요하다.
GET /api/greeting?name=김철수는 query에서 이름을 읽는다
라우트는 method와 path가 맞을 때 실행되고, 핸들러는
req.query.name으로 입력을 읽어
res.send()나 res.json()으로 응답한다.
JSON 파서는 body를 읽는 라우트보다 앞에 둔다
express.json()이 앞에서 실행되어야
req.body가 채워진다. 이후 핸들러가
res.status(200).json(result)처럼 상태와 본문을 보낸다.
404와 에러 핸들러는 마지막 흐름을 맡는다
구체 라우트 뒤에 404를 두고, (err, req, res, next)
에러 핸들러는 정상 흐름 뒤에서 오류 응답 형식을 통일한다.
Express 흐름을 읽을 때는 파일명이 아니라 등록 순서를 따라간다
코드가 여러 파일로 나뉘어 있어도 실제 실행 순서는
app.use와 라우터가 앱에 붙은 순서다. 요청이 멈추면
“응답을 보냈는가, next()를 불렀는가,
next(err)로 오류 경로에 들어갔는가”를 먼저 추적한다.