NestJS 프로젝트 통합

프론트 화면 상태와 Nest API 계약은 같은 실패 지점을 가리켜야 한다

통합은 HTTP 응답을 받는 데서 끝나지 않습니다. DTO shape, 인증 갱신, CORS, error code, loading 상태가 React 화면과 Nest 로그에서 같은 언어로 추적되어야 합니다.

React screen loading, success, error API client base URL, fetch wrapper Auth storage token refresh, 401/403 Error boundary message, retry, fallback Contract seam DTO shape request / response fields Status code 200, 401, 403, 422, 500 Error shape code, message, traceId Nest controller route, DTO validation Guard / CORS preflight, auth failure Exception filter same error envelope Network trace browser evidence Contract test schema drift check 통합 결론 화면 상태표, network trace, contract test, API 로그가 같은 계약 불일치를 가리켜야 한다.
01 화면 상태 React screen loading, success, error가 어떤 API 실패와 연결되는지 고정한다.
02 클라 경계 API client / auth / boundary base URL, token refresh, fallback을 계약 변경과 분리한다.
03 서버 계약 DTO / status / envelope Nest controller, guard, filter가 같은 응답 모양을 낸다.
04 증거 연결 trace / contract test 브라우저 trace와 schema 테스트가 같은 원인을 가리킨다.
1 화면 상태 React 화면의 loading, success, error 상태가 어떤 API 계약에 묶이는지 표시한다.
2 계약 경계 DTO shape, status code, error envelope, traceId를 같은 표준으로 맞춘다.
3 서버 경계 Nest controller, guard, CORS, exception filter가 같은 계약을 반환하는지 본다.
4 증거 연결 network trace와 contract test로 schema drift와 인증 실패를 따로 재현한다.

React 쪽 준비

client

base URL, 공통 fetch wrapper, timeout, retry 기준을 API 계약과 맞춘다.

auth

token 저장 위치와 refresh 실패 화면을 서버의 401/403 응답과 연결한다.

state

loading, empty, success, error 상태가 DTO와 error code를 그대로 표현해야 한다.

NestJS 계약

DTO

request/response field, optional 값, validation error shape를 문서와 테스트에 고정한다.

CORS

preflight, credentials, allowed headers가 브라우저 요청 조건과 맞아야 한다.

error

exception filter가 code, message, traceId를 같은 envelope로 내려야 한다.

불일치 증거

trace

브라우저 network trace로 CORS, status, response body를 화면 상태와 대조한다.

contract

schema 변경은 contract test와 type generation 실패로 먼저 드러나야 한다.

log

frontend error log와 Nest request log가 traceId로 묶이면 원인을 좁힐 수 있다.

01 클라이언트 초기화 API client, auth storage, error boundary, query state를 먼저 맞춘다.
02 DTO 매핑 컴포넌트 상태와 Nest DTO의 필드 이름, optional 값, error shape를 대조한다.
03 인증 실패 재현 token 만료, refresh 실패, protected route, CORS preflight 차단을 따로 본다.
04 계약 테스트 screen state, network trace, contract test가 같은 실패 원인을 가리키는지 확인한다.
정상 흐름

로그인 후 protected route 진입, API 성공 응답, realtime update가 같은 상태표로 이어진다.

장애 흐름

CORS, 401/403, DTO 변경, WebSocket 재연결 실패를 각각 브라우저에서 재현한다.

관측 기준

frontend error log, API error rate, contract test 결과를 traceId로 묶는다.

프로젝트 통합 점검

질문: API 응답 shape, token 갱신, CORS 설정이 브라우저 trace와 일치하는가
순서: API client 준비 -> DTO 매핑 -> 인증/CORS 실패 재현 -> contract test
위험: 서버 테스트만 통과하면 실제 화면의 401/403 처리와 DTO drift를 늦게 발견한다.