TypeScriptSTUDY _ 7장 . 비동기 호출 [ 7.1 API 요청 ]

zeroha·2024년 12월 18일

우아한 타입스크립트 with 리액트 우아한 테크

TypeScriptStudy

목록 보기

20/32

7.1 API 요청

.
.
.

1. fetch로 API 요청하기

외부 데이터베이스에 접근하여 사용자가 장바구니에 추가한 정보를 호출하는 코드 작성
-> 직접 fetch 함수 사용, 사용자가 담은 장바구니 물품 개수를 배지로 보이게...

배지 badge
: 일반적으로 UI에 표시되는 작은 원형이나 사각형 형태의 요소
-> 주로 다른 요소의 옆이나 아이콘 위에 위치하여 사용자에게 새로운 것이 있음을 알려주고자 할 때 많이 사용.

여러 곳에서 같은 API URL을 복붙하여 사용

IF) 백엔드에서 기능 변경을 해야 해서 API URL을 수정해야 한다고 할 때 ?

: 새로운 API 요청 정책이 추가될 때마다 계속해서 비동기 호출 코드를 수정해야 하는 번거로움이 발생.

2. 서비스 레이어로 분리하기

여러 API 요청 정책이 추가되어 코드가 변경될 수 있다는 점을 감안하면 비동기 호출 코드는 컴포넌트 영역에서 분리, 다른 영역(서비스 레이어)에서 처리되어야 함.

fetch 함수를 호출하는 부분이 서비스 레이어로 이동, 컴포넌트는 서비스 레이어의 비동기 함수를 호출 -> 그 결과를 받아와 렝더링하는 흐름.
but !
- 단순히 fetch 함수를 분리하는 것만으로는 API 요청 정책이 추가되는 것을 해결하기 어려움.
- 쿼리 매개변수나 커스텀 헤더 추가 또는 쿠키를 읽어 토큰을 집어넣는 등 다양한 API 정책이 추가될 수 있는데 이를 모두 구현하는 것은 번거로운 일.

3. Axios 활용하기

fetch는 내장 라이브러리라서 따로 임포트,설치 필요 x
but ! 많은 기능 -> 직접 구현해야 함...번거로움

: API Entry가 2개 이상일 경우 각 서버의 기본 URL을 호출하도록 orderApiRequester, orderCartApiRuester같이 2개 이상의 API 요청을 처리하는 인스턴스를 따로 구성해야 함.

4. Axios 인터셉터 사용하기

각각의 requester는 서로 다른 역할 담당하는 다른 서버 -> requester별로 다른 헤더를 설정해줘야 하는 로직 필요할 수도 있음.

-> 이때 인터셉터 기능을 사용하여 requester에 따라 비동기 호출 내용 추가해서 처리 가능 & API 에러 처리할 때 하나의 에러 객체로 묶어서 처리할 수도 있음.

이와 달리 !
요청 옵션에 따라 다른 인터셉터를 만들기 위해 빌더 패턴을 추가하여 APIBuiler같은 클래스 형태로 구성하기도 함.

빌터 패턴 Builder Pattern
: 객체 생성을 더 편리하고 가독성 있게 만들기 위한 디자인 패턴 중 하나.
-> 주로 복잡한 객체의 생성을 단순화, 객체 생성 과정을 분리하여 객체를 조립하는 방법 제공.

이처럼 기본 API 클래스 -> 실제 호출 부분 구성
위와 같은 API를 호출하기 위한 래퍼wrapper를 빌더 패턴을 만듦.

5. API 응답 타입 지정하기

: 같은 서버에서 오는 응답의 형태는 대체로 통일 -> 하나의 Response 타입으로 묶일 수 있음.

Response타입을 apiRequester 내에서 처리하고 싶을 때,
응답이 없을 수 있는 API(UPDATE, CREATE) 처리하기 까다로워짐.

만약 forPass 안에 프론트 로직에서 사용해야 하는 값이 있다면, 여전히 어떤 값이 들어올지 모르는 상태...unknown을 유지.

타입은 언제든지 변경 가능 -> forPass 내의 값을 사용하지 않아야 함.

다만, 이미 설계된 프로덕트에서 쓰고 있는 값이라면 프론트 로직에서 써야 하는 값에 대해서만 타입을 선언한 다음에 사용하는 게 좋음.

6. 뷰 모델 View Model 사용하기

API 응답은 변할 가능성이 크다 -> API 변경에 다른 범위를 한정해줘야 함.

특정 객체 리스트 조회 -> 리스트 각각의 내용과 리스트 전체 길이 등을 보여줘야 하는 화면에서는 해당 리스트를 조회하는 fetchList API 구성.

코드 -

좋은 컴포넌트 : 변경될 이유가 하나 뿐인 컴포넌트
-> 수정해야 할 컴포넌트가 API 1개에 하나라면 좋겠지만, API를 사용하는 기존 컴포넌트도 수정되어야 함.

뷰 모델을 만들면
: API 응답이 바뀌어도 UI가 깨지지 않게 개발 가능
: API 응답에는 없는 totlaItemCount 가은 도메인 개념을 넣을 때 백엔드나 UI에서 로직을 추가하여 처리할 필요 없이 간편하게 새로운 필드를 뷰 모델에 추가 가능.

but!
: 뷰 모델 방식에서도 문제 발생 가능
: 추상화 레이어 추가 -> 결국 코드를 복잡하게 만들며, 개발 비용도 높아짐.

단순히 API 20개 추가 ? -> 20개의 응답이 추가됨.
: 서버와 클라이언트 간의 의사소통 문제 발생 가능.

결국 !
: API 응답이 바뀌었을 때는 클라이언트 코드를 수정하는 데 들어가는 비용을 줄이면서도 도메인의 일관성을 지킬 수 있는 절충안을 찾아야 함.
: 런타임에 API 응답의 타입 오류 방지하려면 Superstruct 같은 라이브러리 사용해야 함.
-> 7번에 나옴.

7-8. Superstruct & 실제 API 응답 시의 Superstruct 활용 사례

Superstruct를 사용 -> 인터페이스 정의와 자바스크립트 데이터의 유효성 검사를 쉽게 함.
Superstruct는 런타임에서의 데이터 유효성 검사를 통해 개발자와 사용자에게 자세한 런타임 에러를 보여주기 위해 고안됨.
모듈마다 데이터의 유효성을 다르게 접근하고 반환 값 형태가 다르다.
- assert : 유효하지 않을 경우 에러를 던짐.
- is : 유효성 검사 결과에 따라 true 또는 false 즉, boolean 값을 반환.
- validation : [error, data]형식의 튜플을 반환. 유효하지 않을 때는 에러 값이 반환되고 유효한 경우에는 첫 번째 요소로 undefined, 두 번째 요소로 data value가 반환.
API 응답 시의 Superstruct 활용 방법을 예시로 본 fetchList 함수
fetchList 함수를 호출했을 때 id와 content가 담긴 ListItem 타입의 배열이 오기를 기대함.
-> 실제 서버 응답의 형식은 다를 수 있음. (TS는 컴파일타임에 타입을 검증하는 역할)