재테크 블로그 프로젝트 (5) - Next.js의 API 사전 연결

개요 : api가 개발은 됐는데 서버이슈로 요청을 못받는 경우엔 어떡해야할까 

프로젝트 진행 중 제공받은 서버가 계속 변동되고 일정에도 차질이 생겨 api연동이 지체되고 있는 상황이다.

프론트엔드의 경우 UI 제작은 어느정도 완료되어서 슬슬 api를 하나 둘 연결해나가야하는데,

마침 api 명세는 상세하게 있어 해당 명세를 통해 api를 사전연결해 로직을 미리 구현하려했다.

 

api 없이 내 생각으로만 미리 로직을 구현하는 것과 큰 차이가 있을지 싶지만 우리팀은 TypeScript를 사용해 개발하기에 props혹은 api 요청, 응답에 대한 타입 정의가 미리 이루어져야하기에 api 명세없이 독단적으로 로직을 짜기엔 향후 수정도 많이 해야한다.

 

다른 방법은 없을까?

→ MSW, PostMan을 이용한 방법이 있지만 우리는 두 가지 상황을 고려해야 했다.

• 이미 연결 검증된 API들 이미 카카오 클라우드를 통해 배포된 서버를 통해 연결한 api가 연결되었는데 굳이 목 서버를 열어 빌드 크기를 늘릴 필요도 없었다.
• 추가로, 아직 나를 포함한 팀원들이 Next에 능숙한 편이 아닌 터에 새로운 기술을 배우면서 api 까지 미리 만든다? 적응하는 차에 api가 나올 것 같았다.
• MSW는 요청을 가로채 응답 상태, 오류 상태에 따른 시뮬레이션에 유리한데 우리는 단순 연결을 최대한 많이 미리 끝내는게 목표에 더 가까워서 MSW에 구미가 당기지도 않았다.
• 따라서 우리가 필요한건 짧은 시일내에 실제 api가 왔을 때의 로직 구현 + 실제 api 적용 전후로의 거의 무방한 차이 이 두 가지가 중요 포인트 이기에 Next.js API Routing을 통한 Mock 데이터 응답을 선택하게 되었다.
• 추가로 언제 문제가 생겨도 mock api를 적용해 다른 기능을 곧바로 테스트 할 수 있으니, 편리성이나 접근성면에서도 우리 요구사항이랑도 일치해 선택하게 되었다.

 

Next JS의 app routing을 이용한 mock api의 전체적인 과정

1. 특정 컴포넌트에서 넥스트 서버 / 로 api요청을 함 api routing 폴더로 요청
2. api route를 통해 handler로 method에 맞는 요청이 가게되고, 해당 파일에선 실 서버로의 요청
3. 서버로의 요청에 대한 응답을 받은 경우 1→2→3 과정을 거꾸로 해 요청한 컴포넌트까지에게 전달
4. 우린 2→3에서의 과정에서 문제가 생긴거니까 이 과정을 생략
5. api route에서 우리가 임의로 정한 응답을 제공

 

추천게시물 요청 api 연결

1. api 연결이 안되기에 mock데이터인 RECOMMEND_ARTICLES 와 카테고리의 경우 변수가아닌 text 자체를 넣어 보여주고있음

아직 api를 통해 데이터를 받아오는 로직이 없는 상황

2. 가장 먼저 해당 컴포넌트가 렌더링 될 경우 데이터를 받아오도록 하는 로직을 넣음

3. 가장 먼저 해당 컴포넌트가 렌더링 될 경우 데이터를 받아오도록 하는 로직을 넣음

• 다음과 같이 useEffect로 api폴더의 recommend로 요청해서 setState하는 함수를 추가
• 그리고 기존의 mockData가 default로 들어있던 state의 배열은 []로 변경
• 이에따라 line 46에선 문제가 발생 기존 같은 경우 mock데이터를 집어넣기에 놓쳤을 빈 배열 문제를 마주할 수 있게됨
  • → 빈 배열(결과가 없는경우)에 대한 처리로직을 생각.
• 그럼 이제 api 폴더로 가보자 원래의 경우 getRecommendPost 를 통해 api요청을 해 응답받아 처리했겠지만 지금은 api가 없다 우리가 mock데이터를 응답해주자

import { NextResponse } from 'next/server';

export async function GET(req: Request) {
  const data = await getRecommendPost(req);
  return NextResponse.json(data);
}

• mock데이터를 넣기 전 데이터가 어떤 형식으로 오는지 확인

 

4. 다음과 같이 오기에 기존에 생성했던 RecommendPostTypes와 다른 부분이 있다면 수정해서 제작

 

5. 다음은 해당 타입을 가진 mock데이터를  백엔드 팀원 분께서 감사하게도 만들어주셨으니 그대로 사용!

 

6. 내가만든 기존의 mock데이터의 경우 사용자의 타입에 대한 응답을 누락했다.

myInterests 필드를 추가한 추천게시물응답 타입을 생성 해당 타입이 이 api result에 대한 타입이 될 것임

 

7. 그럼 이제 추천 게시물 배열 mock데이터 + 사용자의 관심사 mock데이터가 합쳐진 RecommendPostResult에 대한 mock데이터를 만들고, 다시 api폴더로 들어가 해당 mock 데이터를 넣어준다.

 

8. NextResponse로 반환해주는 값도 실제서버요청 값인 data가 아닌 우리의 mock데이터인 recommendResult를 넣어준다.

이제 해당 api를 요청하는 코드로 돌아가 로직을 끝내보자

• 가장 먼저 보이는 도입에 따른 차이는 line 28에서 기존엔 user데이터 존재여부에만 따른 관심사를 보여줌을 api 응답데이터인 datas의 존재여부에따라 다시 보여주도록 구현되었고,
• myInterests가 배열로 올 것을 알았기에 map 함수를 통해 관심사 태그를 차례대로 렌더링하도록 했다.

다음으로는 정적 주소를 넣어줬던 이미지에는 받아온 이미지 배열의 첫 이미지를 썸네일로 보여준다.

만약 없는 경우 지정한 이미지를 보여주도록 했다.

 

연결완료!

 

결론

1. 다른 api와 다르게 구현이 비교적 간단하고 의존성도 낮은 next api route를 활용한 mock api 방식 채택
2. 단순한 mock api를 통한 ui구사와는 다르게 실제 api도입 시 요청 로직만 바꾸면 되는 간편함 + 미리 타입지정을 통한 이후 신속한 개발 가능
3. 기존에는 생각 못했던 예외처리 혹은 로직관련 이슈를 미리 맞닥뜨려 고민해 볼 시간을 가질 수 있다.