API 대응
API 대응
API 영역은 모든 프론트엔드 개발자가 공통으로 사용한다.
초기 조직은 API를 하나의 서버에서 일관된 스펙으로 제공하지만 서비스가 커질수록 API는 여러 담당자와 서버를 거치게 되고 일관되지 않은 API가 되어간다.
프론트에 맞는 스펙으로 변환해주는 프로세스가 필요해짐
도메인이 커지면 여러 서버로부터 API를 받게 되는데 , 이 떄 프론트엔드의 추상화가 중요해진다.
프론트에 맞는 일관적인 스펙으로 전달해주는 과정이 매우 중요
이후 BFF라는 기술 들을 적용해 다양한 프론트 서비스를 이어주는 역할을 진행시켜 발전
Client - Server 1:1 matched
클라이언트에서 하나의 서버만을 바라보고 해당 서버에서 일정한 스펙을 유지하는 경우
프론트의 경우 1:N 또는 BFF를 도입하기 시간적 여유가 있는 케이스
코드상의 부족한 추상화, 리팩토링이 가능하고 발전가능성이 있는 형태의 고민을 해야함
#1. 아키텍처 단위의 커다란 범위 수정하기
#2. REST API를 중앙화를 위한 API 객체 추상화
axios, fetch 등 범용적으로 사용되는 라이브러리를 추상화한 API 객체 제작
프로덕트 전역으로 쓰이는 인증, 인가처리를 포함하는 프로덕트 인증을 위한 API 클래스 객체 제작 필요
API 객체의 주요 역할
환경변수로 전달받은 유기적인 API URL을 래핑하여 필수적인 기능만 추출해주는 역할
추후 라이브러리 교체 및 다양한 확장을 위한 전초 역할
파편화된 API 코드 일원화를 통해 응집도 높이기
이 작업은 추후 1:N 형태로 분리될 때 굉장히 요긴해짐
Last updated
