Route Handlers

Route Handlers는 next 앱에서 서버사이드 로직을 처리함과 동시에 api 엔드포인트를 생성할 수 있게끔 해 주는 기능이다. App router 방식 이전에는 API Routes가 동일한 기능을 수행했다면 App Router 도입 이후부터는 Route Handlers를 사용할 것을 권하고 있다.

App router에서 라우트 핸들러의 생성 또한 동일하게 파일 시스템의 디렉토리 구조를 따르게 된다. 예를 들어 위 사진처럼 App 디렉토리 내에서 api 디렉토리에 route.js | ts 파일을 생성하면 api 엔드포인트는 /api가 된다. (참고로 라운트 핸들러는 App 디렉토리 내에서 생성해야 하며 파일 이름은 route.js | ts로 고정이다)

HTTP methods

Route Handler는 기본적으로 GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS 총 6가지의 HTTP 메소드를 지원하고 있으며, 만약 지원하지 않는 메소드를 호출할 시 405 응답을 반환한다.

위 메소드들을 route.js | ts 파일에서 사용하려면 아래와 같은 방식으로 함수를 생성하면 된다.

// /app/v1/boards/route.ts

export async function GET(req: NextRequest) {
  try {
    const params = req.nextUrl.searchParams;
    return Response.json(await GETCoursesService(params));
  } catch (error) {
    throw error;
  }
}

위 코드는 GET 메소드에 대한 예제이다. 위 코드대로라면 애플리케이션 내에서 /v1/boards에 get 요청을 날리게 된다면, 위 코드의 GET 함수가 호출될 것이다. 따라서 전달받은 요청을 가지고 비즈니스 로직을 수행한 후 가공된 응답을 요청한 클라이언트에 반환할 수 있을 것이다.

Route Handlers, 왜 씀?

Route Handlers 기능을 사용해 api 엔드포인트를 생성하고, ORM 혹은 직접적인 쿼리 조작을 통해 직접 데이터를 받아올 수 있을 것이다. 하지만 실제 프로덕션 프론트엔드 서버 내에서 이를 프론트엔드 로직과 함께 수행하기보다 백엔드 서버로 분리했을 때 적절한 방법일 것이다.

그렇다면 프론트엔드 서버에서 Route Handlers는 어떤 경우에 사용될 수 있을까?

이를 파악하기 위해 먼저 Route Handlers를 사용할 때와 사용 안 할 때의 클라이언트(브라우저) 요청부터 서버의 응답까지 데이터 흐름에 대한 시나리오를 차트로 비교해봤다.

Route Handlers를 안 거치고 바로 백엔드 서버에 데이터 요청

Route Handlers를 거치고 (+ middleware 추가) 바로 백엔드 서버에 데이터 요청

위 차트만 살펴보아도, Router Handlers 기능을 사용하면 클라이언트 단에서 백엔드 서버와 직접적으로 통신하는 것이 아닌, 서버 단인 라우트 핸들러와 통신하는 것을 알 수 있다.

이 말은 즉슨 next 앱이 백엔드 서버와 HTTP 통신을 할 때, 숨기고 싶은 정보들은 서버단인 Route Handlers에서 감추고 필요한 데이터만 가공하여 클라이언트에 제공할 수 있게 된다. 또한 클라이언트에서 하나의 뷰를 완성하기 위해 여러 api 응답 값이 필요한 경우, 클라이언트에서 api를 여러 번 호출하는 것이 아닌, Route Handlers의 route에서 여러 api를 통합적으로 관리해 합성된 api를 단 한번만 호출할 수 있게 된다.

즉, Back-End에서 제공하는 api들을 Front-End에서 다시 한번 재가공하여 커스텀한 api를 만들 수 있는 것이다.