Next14 + fetch interceptor ??

Next14.1.2 버전을 사용하였고 next팀에서 fetch 사용을 권고한다는 걸 보고 fetch를 사용하여 팀프로젝트를 시작했다.

 

프로젝트 초기 진행 중 rest api들의 authorization해더에 accessToken값을 필요로 하는 요청들이 많아 fetch함수에 axios의 interceptor와 비슷한 기능을 구현하기로 마음먹었다.

현재는 authorization 관련된 처리만 하면 되는 상황이였지만 fetch의 init속성(RequestInit)들에 대한 인스턴스를 미리 생성해놓고 사용할 수 있도록 확장성을 고려했다.

 

class FunctionalFetch {
  private init?: RequestInit;

  public setOptions(newInit: RequestInit) {
    this.init = { ...newInit };
  }

  public async fetch(url: string, newInit?: RequestInit) {
    const options = {
      ...this.init,
      ...newInit,
      headers: {
        ...this.init?.headers,
        ...newInit?.headers,
      },
    };
    this.init = options;

    const res = fetch(url, this.init);
    return res;
  }
}

export const authInstance = new FunctionalFetch();

 

간단히 설명하면 FunctionalFetch class를 생성하고, 사용 용도에 따라 코드 맨 아래 줄처럼 인스턴스를 생성했다.

authInstance, otherInstance, etcInstance ... 그리고 rest api를 요청하는 코드에서 해당 인스턴스를 이용해서 authInstance.setOptions()로 미리 해더정보를 set한 뒤 authInstance.fetch()를 할 때 사용했다.
만약 대부분 옵션이 비슷하나 특정 필드만 다른 값을 갖는다면 instance.fetch()를 사용할때 입력해서 기존 속성에 덮어씌워서 사용할 수 있도록 했다.

 

현재 로그인이 성공하면 백엔드에서 응답으로 accessToken을 보내줬고 이를 바로 setOptions에 set하고 instance를 사용했는데 두가지 문제가 생겼다.

 

첫번째는 setOptions를 client component에서 하고 있었는데 server component에서는 인스턴스를 공유하지 않는 것이였다. authInstance가 하나인것 처럼 보이지만 사실은 client단에 1개, server단에 1개 각각 존재하고 있는 상황이였다.

 

두번째는 accessToken을 로그인할때만 백엔드에서 전달 받는데 현재 메모리에만 저장하니 새로고침하거나 다시 페이지가 로드되는 상황에서 메모리가 날라가 저장되었던 셋팅이 사라지는 문제가 발생했다. 

이런 문제들로 인해 쿠키에 accessToken을 저장하고 instance.fetch()에서 this.init에 accessToken값이 없으면 쿠키에서 값을 가져와서 셋팅하는 방식으로 구현했다.

 

if (!isAuthField) {
      if (typeof window !== 'undefined') {
        const token = await getRequestCookies('accessToken');
        this.init = {
          headers: {
            Authorization: `Bearer ${token.value}`,
          },
        };
      } else {
        const { cookies } = require('next/headers');
        const token = await cookies().get('accessToken');
        if (token) {
          this.init = {
            headers: {
              Authorization: `Bearer ${token.value}`,
            },
          };
        }
      }
    }

 

fetch interceptor를 구현하면서 느꼇던 점은 동적인 설정값을 처리하는게 깔끔하지 못했던거 같다. 하지만 정적인 fetch 옵션들을 처리하기에는 좋은 방법인거 같다.

 

추가로 구현 또는 고려할 수 있는 부분
- 각 response status들을 처리하는 로직도 해당 class에서 고려할 수 있을거 같다.

- 현재 client에서 cookies요청 history가 기본적으로 메모리에 저장하고 메모리에 accessToken이 없으면 router handler를 통해서 쿠키의 accessToken을 요청하고 있는데 이게 지연되는 문제가 발생한다면 middleware를 고려할 수 있을 거 같다. header의 authorization 필드에 빈값을 넣어서보내고 middleware에서 authorization 필드 유무를 판단해서 accessToken을 cookies에서 가져온 다음 넣어줘서 보내주는 방법?? 을 고려해볼 수 있을거같다. 사실 성능차이는 정확히 어떨지는 아직 잘 모르겠다.