Next 13과 react 18 서버 컴포넌트 관련 질문 (질문이 좀 길어요)

1번은 next.js 13버전 app에 대해서 공식문서(베타)를 보시면 없어짐을 아실 수 있습니다. 사실상 컴포넌트가 렌더링 되는 방식이 12에선 페이지 단위였다면 13에선 컴포넌트 단위로 변경되다보니 getStaticProps -> ISR or SSG, getServersideProps -> SSR로 페이지단위 렌더링 방식이 고정되는걸 서버컴포넌트와 클라이언트 컴포넌트로 컴포넌트 단위로 렌더링되는 방식이 변경되었다고 이해하시는게 더 나을거 같아요. 2번은 next.js13부터는 컴포넌트가 만약 상태라는걸 갖고 싶다면 클라이언트 컴포넌트를 사용하도록 강제화하고 있습니다. 서버컴포넌트에서 상태는 결국 디비라고 보시는게 더 편할거 같고 전역상태관리도 결국 top down이 아닌 bottom up 방식으로 변경되어감으로써 리덕스나 주스탄스 같이 정말 어플리케이션 전반에 걸치 상태라는 것은 이제 안쓰고 그 역할을 리액트쿼리 같은 캐싱기반으로 대체될것으로 전 생각하고 잇습니다. 3번은 아시다 싶이 가능이 한다는 것뿐이니 작은 서비스가 아닌 이상 백엔드 서버와 프론트엔드 서버는 분리되어야 관리도 용이하며 대용량 서비스에도 더 적합하기 때문에 next.js에 직접 디비를 연결할 일은 잘 없을것으로 보입니다. 4번은 아래의 deno 블로그에 올라온 글을 읽어보심이 더 좋을거 같습니다. https://deno.com/blog/the-future-and-past-is-server-side-rendering 제가 아는 지식선에서 설명을 드리자면 CSR에서 문제가 되었던 부분은 결국 프론트엔드에서 만드는 어플리케이션이 커짐에 따라서 한 화면을 이루는 번들 자체가 커져서 문제가 되었것으로 기억합니다. 추가적으로 모든 코드를 클라이언트에 돌리다보니 보안적인 문제도 있는것으로 알고 있습니다. 결국 SSR로 돌아온 것을 맞습니다만 jsp시절보다 낫다하는 면은 jsp시절에서는 클라이언트에서 렌더링하는 것 한벌, 서버에서 렌더링하는 것 한벌 짜야했던 점이 이제는 next.js와서 한벌로 가능해졌다는 점이 있고 위에서 설명드린 것처럼 한화면 모두 SSR인 것이 SSR과 SSG의 혼합 등으로 조금 더 나은 렌더링방식을 가져가는 것으로 보입니다.

질문에 깊이가 있어보여 전부다 답할수 없음을 미리 양해를 구합니다. 1. 데이터패칭 방식의 변경 아무래도 최신기술이다 보니 기존의 호환성을 유지하기 위해 유틸함수들을 전부다 제거할수는 없습니다. 또한 아직 방법론이랄까 만들어지고 다들 사용해보고 구조를 잡아가는 느낌입니다. 2. 상태관리의 유용성 일반적으로 라이브러리는 기존에 사용하던 툴에서 제공해주지못하는 기능을 제공하기 위해 사용합니다. 따라서 프레임워크단에서 지원해준다면 해당 라이브러를 자연스럽게 도태되거나 아니라면 다른 기능을 추가하는 방향으로 진화될겁니다. 서버컴포넌트와의 상태관리에 대한 예시는 제가 경험해보지못했지만, 상태관리툴에서도 서버컴포넌트와서 상태관리에 대해 지원을 해주지않을까 생각되네요. 3. 서버구성의 변경 극단적으로 바닐라자바스크립트에서 디비에 crud가 당연히 가능합니다. 하지만 그렇게 하지않는 이유는 분리에 있습니다. next를 프론트에만 사용하지않고 api를 사용해서 백엔드 단에서 사용한다면 충분히 가능합니다. 다만 아직까진 레퍼런스가 많이 없고 에러가 나올 가능성이 있어서 쉽사리 도전하기엔 어려워보입니다. 추가로 최근에 next를 백엔드로 사용하는 외주코드를 인수인계받았는데 next 백엔드단에서 터져서 도커가 자주 내려가는 현상이 있었습니다. 다들 경험해보지못한 현상이라 디버깅하기 어려웠어요. 4.다시 20년전으로 제가 20년도부터 프론트를 시작해서 전체적인 역사를 언급할수는 없습니다만, 오히려 서버스 유형에 따라서 확실히 분리되는듯합니다. 유저의 컴퓨팅파워가 필요한 데이터분석 에디터등은 spa로 가고 스트리밍, 서버와의 통신이 빈번힌 서비스는 서버컴포넌트로 가는식으로요. 짧은 식견으로는, 확실히 다양한 것을 시도하고 또 만들어지는 프론트생태계가 아닐까 생각합니다.

잘못된 내용이 있어 정정합니다. 이전에 제 답변을 보신분들께는 심심한 사과를 드립니다 1. getServersideProps 같은 유틸 함수들은 사라지는건가요? -> 사라집니다 2. 만약 전역 상태 관리를 써야하는 컴포넌트라면 서버 컴포넌트가 될 수 없는 것인가요? -> 전역상태 관리를 사용하는 컴포넌트는 서버 컴포넌트가 될 수 없습니다 서버 컴포넌트는 대부분의 hooks을 사용하지 못하므로 상태관리라는 개념이 없습니다 컴포넌트 파일 맨 위에 'use client'라고 적어주시면 이것은 더이상 서버 컴포넌트가 아니게 되므로 상태관리가 가능해집니다. 이 경우 useState 및 전역상태 라이브러리를 사용할 수 있습니다. 모든 전역 상태 라이브러리는 지금까지 쓰시던대로 사용 가능합니다 3. 실 서비스에서도 서버 컴포넌트 - DB 직접 연결 이라는 구조가 성립할 수 있는건가요? 기존에 데이터를 취합하고 내려주던 백엔드 서버의 역할이 생략되는거라고 생각해도 되는건가요? -> 제 견해로는 풀스택 next.js 만으로도 현존하는 서비스의 99%는 대체 가능하다고 생각하는데 대다수의 생각은 그렇지 않은것으로 보이니 백앤드는 그냥 별도의 프레임워크로 작업하시는게 좋겠습니다. 다만 vercel ceo가 모놀리식 개발의 추종자라는 점을 알아두시면 next.js 패러다임과 사용법을 이해하는데 도움이 됩니다 https://rauchg.com/2020/2019-in-review 4. 왜 다시 20년 전으로 돌아가는거죠 -> dx와 ux의 관점에서 설명할 수 있습니다 4.1 UX 향상 잡스러운 라이브러리를 번들링해서 클라이언트에게 넘겨줄 필요가 없으므로 초기 렌더링 속도가 증가하여 빠른 인터렉션이 가능해집니다 4.2 DX 향상 db에서 데이터 가져오는 상황을 (대충) 가정해봅시다 클라에서 useEffect가 호출됨 -> 서버에 API 리퀘스트 -> 서버가 params validation -> DB 쿼리 -> 서버가 DB 응답받아서 클라에 전달 -> 클라가 setState -> 렌더링 위의 과정이 아래의 과정으로 바뀝니다 서버가 DB 쿼리 -> 서버가 DB 응답받음 -> 렌더링 -> 그 외 : vercel ceo가 next.js를 처음 만들었을 때 php에서 많은 아이디어를 가져왔습니다 (예 : zero setup, 파일 기반 라우팅). 덧붙여 vercel 직원 상당수가 전직 php 개발자이며 그들 스스로도 next.js == 더 나은 php/rails 라고 말하는 만큼 앱라우트로의 전환은 필연적인 수순이었을 것입니다

몇 가지 next.js의 공식 문서에서 알리고 있는 내용을 포함해서 이전의 답변들과 본문에 정정이나 정리가 필요한 부분이 있어 보여서 답변을 더해봅니다. 1. next.js의 node script 동작 영역은 app router로 전환된 현재에도 이전과 동일하게 특정되어 있습니다. getServerSideProps로 대표되는 해당 영역은 api route라는 곳으로 한번 다리를 걸친 후 route handler로 옮겨갔는데, 여전히 내부의 로직 구성은 비슷하게 흘러갑니다. context 객체는 각기 쪼개어져 request와 NextResponse로 대체되었고, cookies는 next/cookies라는 모듈로 분화했습니다. param과 query로 명명되어 있는 url의 동적 세그먼트와 쿼리 퍼러미터는 클라이언트인 브라우저에서 존재하는 개념이 되어 hook에서만 다루게 되었는데, 이마저도 next/navigation 모듈이 next/router 모듈 전체를 대체하면서 3개의 개별 훅으로 분화했습니다. 2. server component의 모든 곳에서 fetch를 시도할 수는 있지만, 그것을 내려줄 수는 없습니다. server component를 데이터 요청의 용도로 사용하자면 반드시 promise 객체를 반환하는 컴포넌트로 바꾸어야 합니다. ( 이를테면, async Component function(){} ) 그런데 React.ReactNode는 Promise 객체가 아니기에 하위 컴포넌트는 이것을 적절히 받을만한 방법이 없습니다. 이것이 허용된 유일한 곳이 page.tsx(또는 jsx)입니다. 결국 page 단위로 요청하는 것은 이전과 동일합니다. 여기에 의문이 든다면 이 방법은 사용할 수 있습니다. 말단의 server component가 데이터를 요청하여 받은 뒤 store에 해당 값을 넣는다면, 가능합니다. 허나 이러면 useQuery나 useEffect를 사용하는 client component와 다른 점이 있을까요. 현 시대까지 리액트 생태계에는 통신과 state를 양산하기 위한 "팩토리 컴포넌트"라는 패턴을 만들어 낸 적이 없습니다. component는 view의 렌더링 단위로서 존재했지요. 3. getServerSideProps는 Promise.all의 복제품과 같습니다. getServerSideProps가 반환하는 props 객체는 모든 요청이 완료되고 함수의 실행이 끝난 뒤에 온전히 만들어집니다. Promise.all이나 allSettled와 동일하게 복수 의 요청이라도 어쨌든 한 데 모아서 넘겨준다는 것에서 동작이 같습니다. 현재는 이 방식이 깨졌습니다. app router의 page.tsx에서 동시다발적으로 여러 개의 요청을 하면 이 개개의 요청이 끝나는대로 하위 컴포넌트에서 필요한 데이터를 넘겨줄 수 있습니다. 어딘가를 거치지 않기 때문에 가능하죠. 만약 Promise 객체 그 자체로 넘겨주려 한다면 suspence 컴포넌트를 통해 요청이 fetched된 시점에서 봉인을 풀어줄 수 있습니다. 이 점이 과거와 다른 부분입니다. next.js는 이전의 직렬 순차 렌더링을 waterfall, 현재의 자신의 병렬 개별 렌더링 방식을 streaming이라고 이름합니다. 4. 서버리스 백엔드는 풀스택 프레임워크를 표방하기에 적합합니다. server component, server action, route handler에서 직접 db와 연결하는 경우, 서버라는 중간 계층을 생략할 수 있습니다. 물론 그만큼 검증, 보안 필터가 줄어들기 때문에 어떤 서비스들에는 적합하지 않을 겁니다. 하지만 모든 서비스가 자본의 지원을 받지는 않습니다. 초창기에는 거의 대부분 영세하죠. 경제적인 측면에서 서버리스 백엔드는 런칭하기 쉽고 사업 실패의 리스크가 상대적으로 적다는 이점이 있습니다. vercel은 클라우드 호스트 업체이기도 하기 때문에 고객의 풀을 넓힌다는 측면에서 현재와 같은 형태로 제품 스펙을 변경한 것은 마켓을 염두했을 거라고 볼 수 있습니다.

안녕하세요! Next.js 13과 React 18 서버 컴포넌트에 대한 질문에 답변해 드리겠습니다. 1. 데이터 패칭 방식의 변경 Next.js 13에서도 기존의 `getServerSideProps`와 `getStaticProps`와 같은 함수를 사용할 수 있습니다. 하지만, 서버 컴포넌트를 사용하게 되면 데이터 패칭을 컴포넌트 단위로 할 수 있게 되어 더욱 유연하게 데이터를 가져올 수 있습니다. 서버 컴포넌트는 서버에서만 실행되므로 컴포넌트 내에서 데이터를 직접 가져올 수 있습니다. 따라서 기존의 함수들이 사라지진 않지만, 서버 컴포넌트를 사용하면 데이터 패칭 방식이 변경될 수 있습니다. 2. 기존에 사용하던 상태 관리 프레임워크의 변화 서버 컴포넌트와 클라이언트 컴포넌트가 혼합된 구조에서는 기존의 상태 관리 라이브러리를 계속 사용할 수 있습니다. 서버 컴포넌트에서 데이터 패칭을 처리하면, 클라이언트에서 전역 상태 관리 라이브러리와 함께 사용하는 경우에도 상태를 공유할 수 있습니다. 또한, React Server Components와 전역 상태 관리 라이브러리 간의 호환성 문제도 크게 없을 것으로 예상됩니다. 3. 서버 구성의 변경 서버 컴포넌트를 사용하여 DB와 직접 연결하는 것이 가능하긴 하지만, 실제 서비스 환경에서는 보안 및 설계상의 이유로 별도의 백엔드 서버와 연결하는 것이 더 일반적입니다. 서버 컴포넌트에서 API를 호출하여 데이터를 가져오는 것이 보다 안전하고 확장성이 있습니다. 4. 왜 다시 20년 전으로 돌아가는 걸까요 서버 사이드 렌더링과 클라이언트 사이드 렌더링은 각각 장단점이 있습니다. 서버 사이드 렌더링은 초기 로딩 속도가 빠르고 SEO에 유리한 반면, 클라이언트 사이드 렌더링은 동적인 상호작용에 더 적합하고 서버 부하를 줄일 수 있습니다. ----- ✅ Chat GPT의 답변을 평가해 주세요! - 답변 내용이 올바른지, 틀린 내용은 없는지 댓글로 작성해 주세요.

안녕하세요! Next 13과 React 18 서버 컴포넌트에 대한 궁금증이 여러가지 있으시네요. 답변 드리겠습니다. 1. data fetching 방식의 변경 기존에 사용하던 유틸 함수들이 사라지는 것은 아닙니다. 여전히 사용할 수 있고, 사라지지 않을 것입니다. 단지, 서버 컴포넌트를 사용할 경우 컴포넌트 단위로 data fetching을 할 수 있게 되었기 때문에, 사용하지 않을 수도 있습니다. 따라서, 어떤 방식을 사용할지는 상황에 따라 다르게 결정하면 됩니다. 2. 기존에 사용하던 상태 관리 프레임워크의 변화 서버 컴포넌트가 나오면서, 서버 상태를 컴포넌트 레벨에서 가져올 수 있는 것은 사실입니다. 하지만, 전역 상태 관리 프레임워크가 필요한 경우에도 여전히 사용할 수 있습니다. 예를 들어, 전역 상태 관리 프레임워크를 사용하는 경우, 서버 컴포넌트에서는 전역 상태를 가져오거나 조작하는 것이 어렵기 때문에, 이러한 경우에는 전역 상태 관리 프레임워크를 계속해서 사용할 수 있습니다. 또한, 서버 컴포넌트와 전역 상태 관리 프레임워크의 호환성에 대해서는 아직 자세한 정보가 없으므로, 추가적인 공식 발표를 기다려봐야 할 것 같습니다. 3. 서버 구성의 변경 서버 컴포넌트에서 직접 DB 연결을 하는 것은 가능합니다. 이 경우, 기존에 데이터를 취합하고 내려주던 백엔드 서버의 역할이 생략되는 것은 맞습니다. 하지만, 이렇게 서버 컴포넌트에서 DB 연결을 하는 경우에는, 보안적인 이슈가 발생할 수 있기 때문에, 이에 대한 처리가 필요합니다. 또한, 이러한 경우에는 서버 측에서 처리하는 로직이 더 많아질 수 있으므로, 이에 대한 고민도 필요합니다. 4. 왜 다시 20년 전으로 돌아가는거죠 서버 컴포넌트나 서버 사이드 렌더링이 최근에 다시 각광받는 이유는, SPA(Single Page Application)의 등장으로 인한 문제 때문입니다. SPA는 클라이언트 측에서 렌더링을 하기 때문에, 초기 로딩 시간이 길어지고, SEO(검색엔진 최적화)에 어려움이 있습니다. ----- ✅ Chat GPT의 답변을 평가해 주세요! 틀린 내용은 없는지, 답변이 도움이 되었는지 댓글로 작성해 주세요.