NextJS app router를 사용하면서 생각해볼 것들

NextJS app router를 살펴보면서 궁금한 점 몇가지 정리해보았다.

 

1. Route Handler는 무엇일까?

공식문서에서는 "라우트 핸들러를 사용하면 웹 요청 및 응답 API를 사용하여 지정된 경로에 대한 사용자 지정 요청 핸들러를 만들 수 있습니다."  라고 표현하고 있다.

 

사용법을 보면 아래와 같다.

// 경로 : api/post/route.ts
export async function GET() {
  const res = await fetch('https://data.mongodb-api.com/...', {
    headers: {
      'Content-Type': 'application/json',
      'API-Key': process.env.DATA_API_KEY,
    },
  })
  const data = await res.json()
 
  return Response.json({ data })
}

//사용 예시
 const response = await fetch(`http://localhost:3000/api/post`)

사용법을 보니 한 가지 떠오르는 게 있다.

마치 MSW를 사용하는 것 같이 모킹을 하는 것과 비슷해보인다.

 

🤔그럼 Route Handler는 모킹을 위해서만 사용하는 걸까?

 

아래와 같이 사용할 수 있는 기능들이 있다.

• next의 cookies 사용가능
• 요청 헤더 가져올 수 있음
• 동적 경로 가져올 수 있음
• 쿼리 매개변수를 쉽게 처리할 수 있음

  const searchParams = request.nextUrl.searchParams

• formData를 읽을 수 있음

  const formData = await request.formData()

• CORS 헤더를 설정할 수 있음

export const dynamic = 'force-dynamic' // defaults to auto
 
export async function GET(request: Request) {
  return new Response('Hello, Next.js!', {
    status: 200,
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type, Authorization',
    },
  })
}

• 웹훅을 수신할 수 있음
• UI가 아닌 콘텐츠를 반환할 수 있음(<xml> ...)

 

 

---

 

2. page.js가 반드시 서버 컴포넌트여야한다고?

page.js와 layout.js가 반드시 서버컴포넌트여야한다는 얘기가 있었다.(리액트 Deep Dive 741p 에서)

나는 NextJS를 사용한 프로젝트를 하면서 page.js를 서버컴포넌트로 안한 경우가 있었다.

그래서 이 부분에 대해서 찾아보게 됐다.

 

공식문서에서는 클라이언트 컴포넌트로 설정할 수 있다고 한다.

책은 이전 버전(13.4 이후)을 얘기하는 것 같았다.

현재 14버전은 가능하다고 한다.

 

 

---

 

3. 터보팩이 왜 빠른거야?

SWC와 마찬가지로 "Rust라는 언어로 작성됐기 때문이다." 말하고 있다.

 

도대체 Rust가 뭔데?

Rust는 아래와 같은 특징을 갖고있다고 한다.

 

메모리 안전성

- Buffer Overflow : 프로그램에 할당된 메모리 버퍼의 한계보다 데이터가 넘치게 되면 해당 정보를 덮어쓰고 많은 오류를 발생시킨다.

- Dangling Pointer :  포인터가 해제된 메모리 영역을 가르켜 더 이상 메모리가 유효하지 않게 된다.

 

메모리 안전성이란 Buffer Overflow나 Dangling Pointer와 같은 메모리에 접근할 때 생길 수 있는 문제들에 대해 얼마나 보호받냐를 의미한다.
Rust는 컴파일 시에 메모리 안전성을 확인하므로 컴파일이 된 이후에는 이런 문제를 걱정하지 않아도 된다.

 

안전한 Concurrent programming(동시성 프로그래밍)

- Concurrent programming이란 여러개의 process가 겹치는 기간 동안 교차되어 실행되는 것을 말한다.

Data-race는 두개의 쓰레드가 동시에 메모리에 접근하게 되는 문제로 concurrent programming에서 자주 등장한다.

Rust는 borrow checker라는 것을 이용해서 컴파일 중에 이것을 방지한다.

 

Zero-cost Abstraction

1. 쓰지 않는 기능에 대해서는 성능에 영향을 주지 않는다.
2. 쓰는 기능에 대해서는 추상적으로 코드를 작성하더라도 컴파일할 떄는 가장 low-level하게 실행한다.

한마디로 요약하자면 추상적으로 적은 코드와 해당 코드를 low-level하게 쓴 경우랑 속도가 같다는 것이다.

 

위와 같은 이유라고 한다.

Rust로 개발된 SWC도 같은 이유다.

 

 

---

 

4. 서버 액션(Server Action)

🤔서버액션은 form action에서만 사용가능한건가?

Server Action에 대해서 찾다보면 form의 action을 넣어서 사용하는 방법만 보여주는 곳이 많았다.

서버액션은 form에서만 사용하는걸까? 에 대해서 생각하게 됐고, 다른 예시를 찾아보게 됐다.

 

일단 공식문서에서는 아래와 같이 말하고 있다.

"Server Actions are not limited to <form> and can be invoked from event handlers, useEffect, third-party libraries, and other form elements like <button>."

"서버 액션은 <form>에 국한되지 않으며 이벤트 핸들러, 사용효과, 타사 라이브러리 및 <button>과 같은 기타 양식 요소에서 호출할 수 있습니다."

 

사용예시는 공식문서에서 잘 보여주고 있으니 생략하겠다.👍

 

 

🤔그럼 모든 요청 코드 서버액션을 사용해야 되는건가?

"Server Action을 사용하면 API 클라이언트를 사용하지 않고 브라우저에서 직접 서버 측 함수를 실행할 수 있습니다."

라고 한다.

 

아래 예시를 보자

import { connectDB } from "@/util/database";

export default async function Write2() {
  async function handleSubmit(formData) {
    'use server';
    const db = (await connectDB).db('forum')
    await db.collection('post_test').insertOne({title : formData.get('title')})
  }
 
 
  return (
    <form action={handleSubmit}> 
      <input type="text" name="title" />
      <button type="submit">Submit</button>
    </form>
  );
}

DB에 데이터를 저장, 수정 등을 하고 싶으면 당연히 서버를 거쳐야한다.

그래서 page.js에 <form>같은 것도 만들고 서버 파일로 이동해서 거기에 API도 작성해놔야하는데

위처럼 간단하게 하나의 파일 내에서 form 데이터를 직접 DB에 넣어줄 수 있는 것이다.

 

그리고 revalidatePath를 사용하면 새로고침없이 캐시를 초기화해서 해당 URL에 즉시 새로운 데이터를 불러올 수도 있다.

이를 통해 사용자에게 더욱 자연스러운 사용자 경험을 줄 수 있다.

 

서버액션에 대해 아래와 같이 정리하고 있어 갖고왔다.

- 서버 컴포넌트는 기본적으로 점진적 향상을 지원하므로 JavaScript가 아직 로드되지 않았거나 비활성화되어 있어도 양식이 제출됩니다.
- 클라이언트 컴포넌트에서 서버 액션을 호출하는 양식은 자바스크립트가 아직 로드되지 않은 경우 제출을 대기열에 넣어 클라이언트 하이드레이션에 우선순위를 둡니다.
- 하이드레이션이 완료되면 양식 제출 시 브라우저가 새로 고쳐지지 않습니다.
- 서버 액션은 Next.js 캐싱 및 재검증 아키텍처와 통합됩니다. 액션이 호출되면 Next.js는 한 번의 서버 왕복으로 업데이트된 UI와 새 데이터를 모두 반환할 수 있습니다.
- 서버 액션은 함수입니다. 즉, 애플리케이션의 어느 곳에서나 재사용할 수 있습니다.

공식문서에서는 보안 기능에도 설명하고 있다.

 

여러모로 좋지만 단점도 존재하는 것 같다.

- 서버 코드를 추가하므로 복잡성 증가
- 서버 측에서 더 많은 작업을 수행하기 때문에 서버 부하 증가, 비용 발생
- 클라이언트 측에서만 작동하는 라이브러리 또는 기능 사용 불가
- 서버 측 코드는 클라이언트 측 코드 보다 디버깅이 어렵다.

 

 

🤔서버컴포넌트에서 state,Effect를 사용할 수 없는 이유?

- 서버컴포넌트는 서버에서 딱 한 번 실행 된 뿐 상태를 가질 수 없어 useState나 useReducer를 사용할 수 없다.

- 한 번 렌더링 되면 끝이기 때문에 렌더링 생명주기도 사용할 수 없다.

 

 

 🤔과거 서버사이드 렌더링과 정적 페이지 제공을 위해 이용되던 getServerSideProps, getStaticProps, getInitialProps가 삭제된 이유

- getServerSideProps는 서버컴포넌트의 등장으로 컴포넌트에서 서버에서 데이터를 직접 불러올 수 있고, 비동기적으로 작동하는 것이 가능해졌기 때문에 삭제됐다.

서버 컴포넌트를 사용하게 되면 데이터 패칭을 컴포넌트 단위로 할 수 있게 되어 더욱 유연하게 데이터를 가져올 수 있습니다. 서버 컴포넌트는 서버에서만 실행되므로 컴포넌트 내에서 데이터를 직접 가져올 수 있습니다.

 

- getStaticProps는 이제 정적인 라우팅은 기본적으로 빌드탕미에 렌더링을 미리 해두고 캐싱해서 사용할 수 있게끔해뒀고, 동적인 라우팅에서는 매번 요청이 올 떄 마다 컴포넌트를 렌더링하도록 변경했다.

 

📘마무리 하며..

이번 포스팅은 짧게 작성해봤다.

책에서 Next관련 내용을 읽으면서 "이건 뭘까?", "내가 알던 거랑 다르네?" 하는 것들을 작성해봤다.

사실 디테일하게 따진다면 엄청 내용이 많겠지만 일단은 위처럼 간단하게 추려봤다.

나중에 Next 관련해서 또 궁금한게 생기면 여기에 간단하게 수정해서 올려보려고 한다.