Next.js 13과 ecr + eks로 배포하면서 느낀점 (feat middleware, api route)

프로젝트를 진행하면서 Next.js(v13.1.1) middleware와 api route를 사용하면서 느낀점을 적어보려합니다.

 

api route

왜 썼는가?

인증 관련 처리를 하면서 next-auth 또는 iron-session과 같은 써드파티 라이브러리를 고려하게 되었는데요 그러면서 자연스레 api route또한 고민하게 되었습니다.

인증관련 처리뿐만 아니라 쿠키설정을 어떻게 할지도 고민이 되었는데요, next.js server에서 쿠키설정을 하고 싶은 마음이 있었습니다.

위의 두가지가 가장 큰 동기가 되었고, 추가로 api route를 사용하면서 api 관련 로직들을 api route를 통해 모으기로 했습니다.

조금 더 자세히 이야기 하자면 팀에 백엔드 개발자들이 있어 api route를 통해 직접 db에 접근할 필요는 없는데요, 여러 api들을

한번에 처리하거나 재가공하는 역할을 서버에 위임하였습니다.

단점

경로는 pages/api에 정의되어있는 폴더의 depth대로 결정이 됩니다.

이 부분이 참 불편하다고 느껴졌는데요, restfull하게 api를 명세하려다보니 depth가 깊어지는 경우가 생각보다 많습니다.

도입을 고려한다면 이 부분을 생각해보면 좋을것 같습니다.

주의할 점

api route를 사용해서라기보다 eks + ecr + cloudfront라는 조합으로 빌드 환경을 함께 구성하며 생긴 이슈입니다.

해당 스택으로 빌드환경을 구성할 수밖에 없는 이유가 있었는데요, pod형태로 띄우다보니 scale-out되었을때 비용 이슈가 있기 때문에 cloudfront를 추가로 붙이게 되었습니다.

추가로 위에서 next.js server에서 쿠키설정을 한다고 말을 했는데요, 이 때 cloudfront에서 referer를 잘 설정을 해 주어야 합니다. 인프라 구성 시 next.js server의 origin과 cloudfront의 origin이 다르게 설정되어 있기 때문에 요청이 어디에서 왔는지 header에 잘 기록하고 있어야 서버에서 설정한 쿠키를 front에서 잘 확인할 수 있습니다.

• https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/X-Forwarded-For
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer 
• 위와 같은 키워드로 검색을 해보면 좋을것 같습니다.

middleware

api route를 사용하며 인증관련하여 redirect 및 공통으로 처리되어야할 부분을 middleware에서 다루기로 결정했는데요, 장점으로는 위와 같은 공통로직을 한번에 처리할 수 있는것이 있을것 같습니다.

단점

참… 아직 발전해야하는점이 많다고 느껴집니다. server로 향하는 모든 요청이 middleware로 가게되는데요, 이렇기 때문에 페이지요청을 할 경우 에 대해 검증하는 로직을 추가하고 싶다면 String.prototype.startsWith 메서드를 통해 필터링 하는 예시들을 심심찮게 볼 수 있습니다.

config의 matcher를 통해서도 filter를 할 수 있긴하지만… 두 방법 다 하고싶은 동작에 비해 작성해야할 코드들이 많고 명령형으로 작성해야한다는 느낌이 강하게 들어 결국 middleware대신 다른 방법을 사용했습니다.