axios instance, interceptor에 대하여...

1. axios instance 도대체 왜 쓰는 거야?

: axios instance를 쓰는 가장 큰 이유는 유지보수 때문이다. 그럼 여기서 드는 의문은 왜 유지보수 측면에서 axios instance를 쓰면 좋은지 이다. 이 이유를 설명하기 위해서 다음과 같은 예시가 있다고 하자

axios.get("https://localhost:3000")

이 코드를 보면 localhost 3000포트에 get 요청을 하는 것을 알 수 있다. 근데 만약에 통신을 300번 해야해서 저 코드가 300개 있다고 하자. 근데 만약에 저 localhost 3000포트가 3001포트로 바뀌면 어떻게 하나? 방법은 300개의 주소를 다 바꾸는 것이다. 여기서 우리는 유지보수가 떨어진다는 것을 알 수 있다. 그래서 이를 막기 위해 axios instance를 사용하는 것이다. axios instance의 모습은 이렇게 생겼다.

const test = axios.create({
	baseURL : "https://localhost:3000"
})

test.get("/")

위 코드를 보면 axios.create로 instance를 하나 생성하는데 바로 이 instance가 axios instance이다. 그렇다면 저 구조에서 위와 같은 상황이 올때는 어떻게 할 것인가? 바로 baseURL 하나만 수정하면 된다. 여기서 axios instance는 유지보수가 높다는 것을 알 수 있다.

2. axios interceptor 도대체 왜 쓰는 거야?

: axios interceptor에서 interceptor의 뜻은 가로막는 것이라는 뜻을 가지고 있다. 이름에서 알 수 있듯이 interceptor는 요청과 응답

보내고 받기 전에 그 신호를 가로 챈다는 것을 알 수 있다. 자세히 말하자면 요청을 보내기 전에 요청 해더를 추가 하거나 인증 관리와 관련된 로직을 작성하거나 로그 관련 로직을 삽입하거나 에러 헨들링을 할 수 있다. 나는 여기서 요청과 관련된 interceptor 그 중에서도 에러 헨들링과 관련된 로직을 설명하려고 한다. 먼저 코드는 다음과 같다.

instance.interceptors.request.use(
  function (config) {
    // 요청을 보내기 전 수행
    console.log("인터셉트 요청 성공!");
    return config;
  },
  function (error) {
    // 오류 요청을 보내기 전 수행
    console.log("인터셉트 요청 오류!");
    return Promise.reject(error);
  }
);

위 코드를 보면 요청을 보내기 전에 2가지의 함수를 통해서 error와 success를 헨들링하는 것을 확인할 수 있다. 즉 이런 방식을 통해서 에러 헨들링, 로그 설정, 인증 관리, 요청 헤더 추가 등을 할 수 있다.