Next.js Server Actions 관련 정리문제 상황Next.js 애플리케이션을 Nginx로 배포 후 "Invalid Server Actions request" 오류 발생화면은 정상적으로 로드되지만 서버 요청(로그인 등)에서 500 오류 발생예: POST https:/주소명 500 (Internal Server Error)원인Next.js 14부터 Server Actions에 대한 보안이 강화됨기본적으로 동일 출처(same-origin) 요청만 허용하며, 다른 도메인은 명시적 허용 필요Nginx와 같은 리버스 프록시 사용 시 헤더가 제대로 전달되지 않는 문제CSRF(Cross-Site Request Forgery) 공격 방지를 위한 보안 조치해결 방법next.config.js 파일에 allowed..
Next.js
클라이언트 라우터 캐시브라우저에 저장되는 캐시로 페이지 이동을 효율적으로 진행하기 위해 페이지의 일부 데이터를 보관한다.클라이언트 라우터 캐시 동작과정 먼저 이전 게시물의 풀 라우트 캐시에 의한 동작과정을 살펴보면 다음과 같다. 먼저 인덱스 페이지에 초기 접속 요청을 보내면, 인덱스 페이지의 경우는 정적인 페이지이기 때문에 next 서버에 있는 풀 라우트 캐시에 인덱스 페이지가 저장되어 있는지 확인하고 풀 라우트 캐시된 데이터가 있으면 그대로 반환하고 서치 페이지 같이 동적인 페이지에서 풀 라우트 캐시는 스킵되고 사전 렌더링 과정을 통해 렌더링된 페이지를 반환하게 된다. 하지만 이런 과정을 보면 사실 비효율적일 수 있는데, 그 이유는우리가 전달 받은 페이지 데이터는 HTML, JS Bundle, RSC ..
풀 라우트 캐시(Full Route Cache)풀 라우트 캐시란 Next 서버 측에서 빌드 타임에 특정 페이지의 렌더링 결과를 캐싱하는 기능을 말한다. 그림과 같은 과정에서 /a 라는 경로를 갖는 페이지가 풀 라우트 캐시를 가질 수 있는 페이지라고 할때, 빌드 타임 시 사전렌더링과정에서 먼저 리퀘스트 메모이제이션과 데이터 캐시 등의 캐시 과정들을 거쳐서 렌더링이 완료가 되면 완료된 렌더링 결과를 Next 서버 측 풀 라우트 캐시라는 곳에 미리 저장하게 된다. 그래서 실제로 빌드 타임 후 서버를 가동하여 /a 라는 경로로 접속을 요청하게 되면 빌드 타임에 미리 렌더링해서 풀 라우트 캐시에 저장된 렌더링 결과를 불러오기 때문에 새롭게 렌더링할 필요가 없이 캐시된 페이지를 그대로 브라우저에게 전송하여 빠른 ..
1. 데이터 캐시(Data Cache)먼저 데이터 캐시란 Fetch 메서드를 활용해서 api 서버로 부터 불러온 데이터를 넥스트 서버 측에서 캐싱해두는 그런 기능을 말한다. 그래서 이러한 데이터 캐시를 이용하며 영구적으로 데이터를 보관하여 불필요한 데이터 패칭의 요청을 방지하거나 특정 시간을 주기로 데이터를 갱신시킬 수 있다.const response = await fetch(`~api`, { cache: "force-cache" }); 그래서 위와 같이 fetch 메서드의 두 번째 인수로 객체 형태의 추가적인 옵션을 설정하여 캐시를 적용할 수 있게된다. 캐시 옵션에는 위와 같이 다양한 옵셥이 존재한다. 참고로 next 앱에서 데이터 캐시의 옵션은 Fetch 가 아닌 Axios 등의 다른 HTTP Re..
앱 라우터의 서버 컴포넌트 도입으로 인해 데이터페칭 방식이 기존의 방식과 변하여 데이터를 페칭한다. 먼저 기존의 페이지 라우터에서 데이터를 페칭하는 방식에는 SSR, SSG, Dynamic SSG 방식이 있었고, 이런 방식을 이용해 데이터를 직접 페칭하여 이 데이터를 페이지 컴퍼넌트에 props 로 넘겨주는 구조로 데이터를 페칭하였다. 이러한 페이지 컴포넌트는 사전렌더링 과정에서 서버측에서 한번 브라우저 측에서 하이드레이션 과정에서 한번 더 실행되어 데이터를 불러오기 위해서는 GetServerSideProps 나 GetStaicProps 등등의 특수한 함수를 이용했어야 했다. 하지만 서버 측에서 불러온 데이터를 컴포넌트 트리 최상단에 위치하는 페이지 컴포넌트에게만 props 로 전달이 될거기 때문에 데이..
App Router 에서도 기존의 Page Router 버전과 동일한 방식으로 네비게이팅, 페이지 이동을 한다. 하지만 App Router 에서 부터 서버 컴포넌트를 사용하여 차이점이 하나 발생한다. JS Bundle 파일 뿐만 아니라 RSC Payload를 같이 보내주는데, 그 이유는 JS Bundle 는 클라이언트 컴포넌트만 포함되어 있어 RSC Payload 를 통해 서버 컴포넌트 까지 같이 보내준다. 그렇지 않으면 클라이언트 컴포넌트만 보내게 되어 서버 컴포넌트로 구성된 부분의 데이터는 브라우저에서는 누락이 되어 정상적으로 페이지를 이동할 수 없게 된다. 그래서 App Router 에서는 페이지 이동 요청시 JS Bundle 과 RSC Payload를 함께 전달하게 된다.네비게이팅을 통한 페이지..
기존의 page router 방식에서 사전렌더링 과정은 위와 같이 서버 측에서 JS 실행(렌더링), 자바스크립트 코드(React 컴포넌트)를 HTML으로 변환하여 화면에 렌더링 후 화면과 상호작용을 위해 Next 서버가 브라우저에 후속으로 모든 자바스크립트 코드 즉 리액트 코드를 번들링 해서 브라우저에 보내는 하이드레이션 과정을 통해 상호작용이 가능토록 하는 사전 렌더링 방식을 지녔다. 그러나 이런 방식은 다소 비효율적일 수 있는데 그 이유는 Page Router의 경우는 한 페이지 내에 코드를 onClick 같은 브라우저에서 하이듀레이션 해주어야 하는 컴포넌트(상호작용이 있는 컴포넌트) 뿐만 아니라 상호작용이 없는 컴포넌트 또한 JS Bundle 를 통해 전달해주기 때문이다.그래서 전달되는 JS Bun..
App Router란?next 13 버전에 새롭게 추가된 라우터로 기존의 Page router 를 대체한다. 그래서 기존의 Page router 방식에서 달라지는 점은 아래와 같다. 1. 변경되거나 추가되는 사항페이지 라우팅 설정 방식레이아웃 설정 방식데이터 페칭 방식 변경React 18 신규 기능 추가React Searver ComponentStreaming그리고 크게 변경되지 않는 사항도 있는데 2. 크게 변경되지 않는 사항네비게이팅프리페칭사전 렌더링이 부분들은 크게 변경되지 않았다고 한다. Next.js 15v 설치하기npx create-next-app@rc (폴더 이름) 그 이후에 설치와 관련된 선택사항은 위와 같이 기본적으로 설정하나 이후에는 상황에 따라 선택하면 될 것 같다.App Router..
