`API 언제 나오나요?` 로 부터 독립하기

API 응답 모델이 확정되지 않은 상태에서 UI 개발을 먼저 진행해야 할 때, API 레이어와 UI 컴포넌트 사이에 factory 레이어를 하나 넣어 의존을 끊은 사례다. 프론트가 예측해 모킹한 모델과 실제로 확정된 응답이 얼마나 어긋나는지를 항목별로 대조해 보여준 뒤, 그 차이를 흡수하는 지점을 한 곳으로 모은다.

핵심 포인트

API 정보가 없으면 서버 개발자로 빙의해 응답을 예측해 모킹하게 되고, 그렇게 쌓인 코드는 확정 시점에 리팩터링 수준의 변경을 부르는 레거시가 된다.
실제로 어긋난 지점은 API 호스트 분리, 같은 UI 에 서로 다른 데이터 모델(VOD 는 array·LIVE 는 object), snake_case 필드명, thumbnail 이 문자열이 아닌 객체, 상태에 따라 다른 thumbnail, 배열 요소의 키 래핑, running_time 단위(ms 가 아니라 sec)였다.
해결은 Facade 와 비슷한 구조의 factory 레이어다. API 응답이 어떻게 오는지에 대한 관심사를 전부 factory 가 가져가고 UI 는 화면에 필요한 prop 만 받는다.
RTK Query endpoint 로 factory 를 구성하면 `isFetching` 같은 상태값과 캐시·폴링 관련 옵션들을 factory 단위로 쓸 수 있다.
그 결과 description 에 무엇이 들어가는지, 콘텐츠가 live 인지 vod 인지조차 UI 컴포넌트가 몰라도 되고, 좋아요 수 표기 같은 스펙이 추가돼도 UI 는 그대로 둔다.

상세 정리

상황 설정: LIVE 와 VOD 콘텐츠를 가로로 나열하는 리스트 화면을 API 정보 없이 먼저 만들어야 했다.
1차 시도: 이상적인 형태로 데이터 모델을 예측해 모킹하고 UI 컴포넌트를 만들었다. 다른 화면들도 같은 방식으로 쌓이면서 확정 시 대규모 변경이 불가피하다는 것을 인지한다.
미스매치의 성격: 프론트는 구조적으로 이상적인 모델을 예측하지만 실제 API 는 여러 사정으로 이상적이지 않다. 이 어긋남은 언제나 존재한다는 것이 전제다.
레이어의 위치: API 레이어와 UI 컴포넌트 사이. 변경이 생기면 factory 한 곳만 고치면 되도록 주석으로도 "API 가 변경되면 이곳에서만 수정" 을 명시해 뒀다.
UI 쪽 효과: 서버가 준 포맷이 예상과 다르더라도 컴포넌트는 전달받은 text 를 스타일에 맞게 뿌리는 일만 한다.
확장 효과 ①: API 로부터 독립됐기 때문에 테스트 코드를 일찌감치 확정 지을 수 있다.
확장 효과 ②: 로깅에 필요한 데이터를 만들거나 userAgent 에 따라 분기 처리를 할 때도 factory 에 위임해 UI 컴포넌트를 간결하게 유지할 수 있다.

왜 읽나백엔드 스펙이 안 나온 채로 화면부터 만들어야 하는 프론트엔드 개발자에게, 나중에 터질 변경을 한 파일로 모으는 구체적인 배치를 보여준다.

카카오 엔터테인먼트 FE 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청