async

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음.

사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async.

자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

Next.js15 가 정식 버전으로 출시되었습니다. 이번 릴리즈는 React19와 긴밀하게 통합하여 React19 RC 버전을 채택하고 React 컴파일러에 대한 지원도 추가되었습니다. 역시 Next.js와 리액트는 한몸이네요. 주요 변경사항은 아래와 같습니다.

1. 코드베이스 업그레이드 자동화(@next/codemod) : TanStackQuery@V5와 같이 codemod를 통한 손쉬운 업그레이드를 지원합니다. 의존성 패키지 자동 업데이트 및 코드 자동 변환 기능을 제공한다고 하네요.

   
   

2. SSR 렌더링 최적화(Async Request APIs): SSR 성능 개선을 위한 새로운 접근 방식 인데요. 데이터 의존성이 있는 컴포넌트를 async로 명시적으로 구분하여 데이터가 필요없는 컴포넌트는 사전 렌더링하여 전체 성능을 향상시켰습니다. 스트리밍SSR과 비슷한 최적화 개념인것 같습니다.

   
   

3. API Route 캐싱 정책 변경: GET Handler의 기본 캐싱을 비활성화 했습니다. 이유는 PPR(Partial Prerendering) 호환성 문제, 기본값이 캐시되는 것이 항상 최선은 아니라는 피드백을 반영하였습니다.

   
   

4. Turbopack 정식 버전으로 전환: Next.js의 개발 서버 번들러인 Turbopack이 정식 버전으로 릴리즈되었습니다. 아직도 기본 번들러는 Webpack이지만, Rust로 작성된 Turbopack에 많은 투자를 하고 있는만큼 머지않아 기본 번들러가 Turbopack으로 전환될 것 같네요.

이번 업데이트 역시 개발자 경험 개선(DX) 개선과 성능 향상에 중점을 두었습니다. 그리고 Turbopack이 안정화 되었고 매우 빠른 속도를 제공하는 만큼 개발 모드에서는 Turbopack을 사용하고 배포에서는 안정적으로 webpack을 사용해봐도 좋을것 같습니다.

https://nextjs.org/blog/next-15

1. Vitest의 vi.mock 은 ESModule import를 넣을 수 있다.

장점: IDE에서 import 경로를 추적할 수 있어서 경로를 업데이트 할 때 같이 바꿔주기 때문에 실수를 줄여줍니다.

- jest.mock('axiost')
+ vi.mock(import('axios'))

2. Vitest의 vi.mock 은 두 번째 인자로 부분 모킹이 가능하다.

장점: 모듈에 타입 지원이 됩니다.

- jest.mock('ant-design', () => ({
-   ...jest.requireActual('ant-design'),
-   Typography: jest.fn().mockImplementation(({ children }) => <div>{children}</div>),
- }));

+ vi.mock(import('ant-design'), async (importOriginal) => ({
+   ...(await importOriginal()), // ((parameter) importOriginal: <typeof import("ant-design")>() => Promise<typeof import("ant-design")>)
+   Typography: vi.fn().mockImplementation(({ children }) => <div>{children}</div>),
+ }))

https://vitest.dev/api/vi.html#vi-mock

App Router는 Next.js의 진화된 라우팅 시스템으로, 기존의 pages/ 디렉토리 기반 라우팅에서 벗어나 새로운 app/ 디렉토리를 통한 라우팅 방식을 도입합니다. 이 시스템은 Next.js의 철학에 따라 모든 기능이 라우터 중심으로 설계되었으며, 페이지 전환, 데이터 페칭, 캐싱, 데이터 변경 및 재검증, 스트리밍 등의 과정을 포괄적으로 관리합니다.

주요 특징:

1. 서버 중심 라우팅: App Router는 React Server Components를 기반으로 구축되었으며, 이는 서버에서 데이터를 효율적으로 가져오는 데 중점을 두고 있습니다.

2. SPA와 유사한 경험: 경로 변경 시 전체 페이지를 리렌더링하지 않고, URL만 업데이트하여 필요한 세그먼트만 렌더링함으로써 단일 페이지 애플리케이션(SPA)과 유사한 사용자 경험을 제공합니다.

3. 코드 단순화 및 최적화: layout, loading, error.js 등 핸들링을 위한 다양한 파일들이 제공되어, 각 상황에 맞는 코드가 파일 내에 존재함으로써 코드의 복잡성을 줄여줍니다. Ex)코드레벨에서 if(error){} 등의 코드가 불필요

4. 서버 컴포넌트 및 클라이언트 컴포넌트: app/ 디렉토리 내의 파일은 기본적으로 서버 컴포넌트로 작동하며, 이는 초기 페이지 로드 속도를 개선하고 캐시 가능성을 높입니다. 클라이언트 컴포넌트는 use client를 명시함으로써 사용할 수 있는데요 클라이언트 컴포넌트란 useState, useEffect 훅을 사용하거나 브라우저 API 의존성이 있거나 특정 이벤트 리스너(onClick, onChange)를 추가하는 경우가 이에 해당 합니다. 그리고 클라이언트 컴포넌트에서는 서버 컴포넌트를 import 할 수 없고 클라이언트 컴포넌트를 트리의 leaf 노드에 가깝게 설계하는것이 좋습니다.

5. 데이터 페칭의 단순화: getServerSideProps, getStaticProps, getInitialProps와 같은 메서드를 더 이상 사용하지 않고, 리액트 서버 컴포넌트 기반 이기 때문에 async/await 문법을 사용하여 서버 데이터를 직접 가져올 수 있습니다. 이는 next/build 시 데이터 페칭을 수행하고 캐싱하는 방식으로, 기존의 useEffect를 사용한 데이터 페칭과 상태 변경 방식에서 벗어남으로써 성능을 개선합니다.

그렇지만 App Router는 아직은 초기 단계로, 일부 라이브러리(예: MSW, Emotion)와의 호환성 문제가 있을 수 있습니다. 또한 기존 Page 기반 라우팅 에서 지원되던, 라우터 이벤트 및, 내장 i18n 지원의 부재, 초기 버그 등 몇 가지 단점이 존재합니다.

그렇지만 이러한 측면을 고려하더라도, App Router는 지속적인 업데이트가 기대되는 만큼 통해 성능 향상에 중요한 역할을 할 것으로 보입니다. Vercel 에서는 App 라우팅 시스템의 사용을 권장하고 있기 때문에, 향후 더 안정적이고 성능이 우수한 웹 애플리케이션 개발을 위한 중요한 도구로 자리 잡을 것으로 보입니다.

https://nextjs.org/docs/app

React가 클래스 컴포넌트에서 함수 컴포넌트를 개발하고 사용을 권장해서 현재는 대부분 함수 컴포넌트로 개발을 하고 있는데요.

Next.js 에서도 최근 앱 라우터를 출시해서 페이지 기반 라우터에서 앱 라우터의 사용을 권장하고 있습니다. 앱 라우터는 기본적으로 모든 컴포넌트가 서버 컴포넌트 입니다. 따라서 React개발 흐름이 '리액트 서버 컴포넌트' 라고 불리우는 'RSC'로 방향을 이어가고 있는데요. 따라서 React개발자는 이러한 변화에 맞추어 이 기술을 활용하고 적응해야 합니다. 그럼 이 RSC는 무엇일까요?

클라이언트 사이드 UI 라이브러리

리액트는 초기에 아주 간단한 클라이언트 사이드 UI라이브러리 였습니다. 큰 컴포넌트를 작은 컴포넌트 조각으로 나누는것을 제안했습니다. 자체 비공개 데이터인 State 와 데이터를 전달하는 방법인 Props로 컴포넌트 계층 구조를 나누고 데이터 흐름을 관리했습니다. 자바스크립트 함수를 통해서 말이죠.

그렇다면 기존 리액트 앱의 문제는 무엇이었을까요?

1. JavaScript 파일 크기로 인한 초기 로딩 시간 지연: SSR을 통해 어느정도 문제를 해결할수는 있지만, 여전히 클라이언트에서 추가적인 JavaScrip를 실행해야 합니다.

2. 네트워크 워터폴로 인한 클라이언트 컴포넌트 응답 지연

3. 레이아웃 이동 문제: 네트워크 API응답 순서에 대한 보장이 없다보니, 지연 시간 등의 요인에 따라 컴포넌트 로딩 순서가 여러 요인에 따라 달라집니다.
   

이러한 문제를 해결하기 위해 React 컴포넌트를 서버로 옮기는 구상을 하게 됩니다.

컴포넌트가 서버에 있으면 데이터를 미리 가져오고 처리하여 클라이언트에 전달함으로써, 클라이언트는 렌더링에만 집중할 수 있게 됩니다.

따라서 초기 로드 시간을 단축하고 네트워크 효율성을 개선할수 있는 일종의 패러다임의 전환 이라고 볼수 있는데요.

RSC는 다음과 같은 특징이 있습니다.

1. 비동기 호출을 처리해서 컴포넌트가 async 타입이다.

2. 컴포넌트 자체에서 DB에 연결이 가능하다(Express 처럼)

3. console.log를 찍으면 브라우저 콘솔이 아닌 서버 콘솔에 찍힌다.

또한 다음과 같은 주의사항이 있습니다.

• 사용자 인터렉션을 추가할 수 없다(이벤트 핸들러)

• LocalStorage 같은 브라우저 웹 API를 사용할 수 없다.

• 클라이언트 상호 작용과 관련된 것은 클라이언트 컴포넌트를 사용해야 한다.

크롬의 Source탭에서는 클라이언트 컴포넌트 JavaScript 코드를 확인할 수 있습니다. RSC는 서버에서 실행되고 처리되어 Source탭에서는 확인할수 없고 서버의 코드를 직접 확인해야 합니다.

위 내용과 관련하여 더 자세한 내용을 알 고 싶으신 분은 아래 사이트를 방문해서 보시는것을 추천드립니다.

https://www.freecodecamp.org/korean/news/how-to-use-react-server-components/