제가 알고있는 ssr의 장점이 맞는지 궁금합니다

Question

팀프로젝트에서 제가 알고있는 정보와 다른 정보가 나와서 만들어본 ppt자료 입니다.팀원 의견은 빈번한 통신이 이뤄지는경우 ssr이 csr보다 적합하다는 의견이였고저는 빈번한 통신의 경우 ssr이나 csr이나 큰차이가 없다는 의견이 였는데제가 작성한 자료와 주장이 알맞은 정보를 포함하고 있는지, 의견을 뒤바침하는 내용이 맞는지 궁금합니다.또한 이해하기 어려운내용이 있다면 말씀해주세요 감사합니다.

chytonpide · Answer

잘 정리하신것 같은데요? 결론도 정확한것 같아요.

크흐흠 · Answer

다시 확인해보니까 seo를 sso로 오타낸게 있었네요

풍월상신(가니메디안) · Answer

CSR, SSR 분류는 지나친 단순분류라고 생각하고요.NextJS 의 모든 컴포넌트는 디폴트로 RSC 입니다. 꼭 필요한 경우에만 클라이언트 컴포넌트로 선언해서 예외적으로 사용합니다.SSR 에도 비용이 발생하기 때문에, 엣지 서버 활용과 최적화를 위해 프리렌더링된 static 문서를 빌드 시점에 생성해줄 수 있습니다. Static 빌드와 관련된 여러 옵션 중 하나가 SSR 일 뿐입니다. (SSG, ISR, DSG, ODR, SSR)그리고, 'SSO 최적화' 라는 표현은 아마도 'SEO 최적화' 의 오타이겠죠.참고로, 제가 정리해 놓은 내용을 아래 붙여봅니다. 다 올라갈지는 모르겠네요.목차SSG : Static Site GenerationISR : Incremental Static RegenerationDSG : Deferred Static GenerationODR : On-Demand RevalidationESR : Edge-Side RenderingSSR : Server Side RenderingStatic First, Dynamic as Neededfetch()generateStaticParams()getStaticProps()getStaticPaths()revalidatePath()revalidateTag()fallback & revalidateStatics & Dynamic 혼합 구성...#3. SSG, ISR, SSR...NextJS 는 Static 문서를 생성할 수 있습니다.기존의 React 는 오직 클라이언트 사이드에서 데이터를 불러와서 페이지를 렌더링 해주었죠. 이 방식을, Client-Side-Rendering CSR 이라 일컫습니다.그러나, NextJS 에서는 모든 컴포넌트가 디폴트로 RSC React-Server-Component 라고 배웠죠. 그리고 서버 컴포넌트는, 서버단에서 data 를 불러오고 렌더링까지 마친 후에, 완성된 Dom 을 클라이언트에게 전송합니다. 이를, 서버에서 렌더링된다는 의미로, Server-Side-Rendering SSR 이라 일컫습니다.SSR 은, 페이지가 ‘호출될 때마다’ 서버에서 렌더링 됩니다. 서버사이드 캐시가 있으면 더 좋겠다는 상상을 하게되죠. 매 번, 새롭게 렌더링 될 필요 없이, 캐시된 페이지를 보내주는 것이 서버자원과 응답속도 면에서 효과적일 것입니다.SSG 는 Static Site Generation 으로, 서버의 모든?? 또는 일부?? 다이내믹 문서를, 앱의 빌드 시점에 Static 문서로 생성한다는 발상입니다. 그리고 이 발상이 가지에 가지를 치고, 더 복잡한 Cache 또는 Static 문서 관리의 규칙들로 이어지게 됩니다. 그 규칙들을 하나씩 알아보죠.SSG : Static Site GenerationSSG 는, 페이지를 호출할 때마다 서버에서 렌더링하는 SSR 과 다르게, 앱의 빌드 시점에 사전 렌더링이 완료됩니다. 빌드시 정적인 Static 페이지가 생성되고 사용자의 요청이 있을 때, 사전에 생성된 정적인 페이지가 제공되는 것이죠.주의!!!개발서버에서는 작동하지 않습니다. 개발서버의 목적과 부합하지 않기 때문이죠. SSG 에는 매우 긴 빌드타임이 필요한데요. 각 다이내믹 페이지마다 백엔드 fetch 가 발생하기도 하죠.이 때문에 즉각적인 피드백이 목적인 개발서버에서는 generateStaticParams, getStaticProps, getStaticPaths, revalidatePath, revalidateTag 등의 SSG 펑션 코드를 스킵합니다.SSG 의 작동을 확인하려면, 앱을 빌드한 후 프로덕션 서버를 시작해야 합니다.npm run buildnpm run start관련 펑션:generateStaticParams()Ref:https://nextjs.org/docs/app/building-your-application/caching#generatestaticparamsISR : Incremental Static RegenerationSSG 와 마찬가지로, 앱의 빌드 시점에 사전 렌더링이 완료되고, 사용자의 요청이 있을 때, 사전에 생성된 정적인 페이지가 제공되지만, 정적인 페이지에 그 수명이 지정됩니다. static 페이지의 수명이 다하면, 그 시점에 static 페이지가 새롭게 렌더링 & 재생성됩니다.Static 페이지 Re-Validation:App Router : page.tsx 에 다음 처럼 추가해줍니다.export const revalidate = 600 // 10분 수명의 ISRPages Router : getStaticPaths 펑션의 return 객체에, 다음 처럼 추가해줍니다.revalidate = 600 // 10분 수명의 ISR개발서버에서는 작동하지 않습니다.관련 속성:revalidateRef:https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#revalidateDSG: Deferred Static GenerationDSG 은, 앱의 빌드 시점에 Static 이 생성되지 않고, 처음 페이지가 요청되었을 때 서버에서 Static 문서를 생성합니다.즉, DSG 이 선언된 page.tsx 에서는,첫 요청은 SSR 로 렌더링 되고 응답합니다.첫 요청에서 렌더링 된 페이지는 서버에 저장되고, 이후 요청에는 생성된 Static 문서가 응답됩니다.DSG 이 사용되는 이유:빌드 시간 단축서버 리소스 절약모든 동적인 페이지에 대해서 Static 을 생성해줄 수 없을 때이미 오래된 토픽을 다루면서, 요청이 발생할 것이라는 확신이 없을 때// // DSG를 위한 설정 // dynamicParams 가 true 일 때, DSG 가 적용됩니다. export const dynamicParams = true; export async function generateStaticParams() { // 초기에 생성해야 할 정적 페이지가 있다면 여기서 반환 // 이 목록에 대해 SSG 가 적용되고, 앱이 빌드될 때 Static 이 생성된다. // 예: 가장 최근 게시물 ID들 return [ { id: '1' }, { id: '2' }, { id: '3' }, ]; } export default async function Post({ params }: { params: { id: string } }) { const post = await getPost(params.id); return (

{post.title}

{post.content}

); } 그리고 주의할 점은, 개발환경에서는 기대한 대로 작동하지 않습니다. 빌드 이후에 작동합니다.개발서버에서는 작동하지 않습니다.관련 속성:dynamicparamRef.https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#dynamicparamsODR : On-Demand Revalidation특정 이벤트나 변화가 있을 때, 또는 관리자가 수작업으로, path 또는 tags 에 대한 Re-validation 작업을 해줄 수 있습니다.Revalidation 이 작동하면, SSG, ISR 로 생성된 해당 Static 문서들이 무효화되고 새롭게 렌더링, 생성됩니다.이 우아한 방식은 아래 관련 펑션을 다룬 소 항목에서 자세히 다루겠습니다.개발서버에서는 작동하지 않습니다.관련 펑션:revalidatePath, revalidateTagRef:https://nextjs.org/docs/app/api-reference/functions/revalidatePathESR : Edge-Side RenderingEdge Server 란, 한 네트워크가 다른 네트워크와 연결되는 공간에 위치하는 서버입니다.흔히 CDN 으로 알고 있는 그 CDN 과 비슷하다고 이해하면 될 것 같습니다. Vercel 에게도 독자적인 Vercel Edge Network 가 존재하는데, 전세계에 분포되어 있다고 알려져있죠.ESR 은, 전세계의 Vercel Edge Network 중, 사용자에게 가장 가까운 엣지 네트워크에서 SSR 이 이루어집니다. 물리적 위치가 가까워짐으로 인해 얻는 이점이 있다고 알려져 있습니다.작동방식의 특성상, ESR 과 SSG 의 혼합사용은 불가능합니다.// // app/posts/[id]/page.tsx // Enable Edge Runtime for Edge-Side Rendering export const runtime = 'edge'; // Force dynamic rendering to ensure the page is rendered on every request export const dynamic = 'force-dynamic'; export default async function Post({ params }: { params: { id: string } }) { // Fetch data using Edge Rendering const data = await fetch(`https://example.com/api/posts/${params.id}`, { cache: 'no-store', // Disable caching to always fetch the latest data }).then((res) => res.json()); return (

{data.title}

{data.body}

); } 참고로, Edge Runtime 은 streaming, webSocket 등의 용도에서 주로 사용됩니다. ESR 은 오바인 듯개발서버에서는 작동하지 않습니다.SSR : Server Side Rendering서버사이드에서 데이터를 포함한 Dom 이 렌더링 되어서 클라이언트에게 제공됩니다.NextJS 에서 모든 디폴트 컴포넌트의 렌더링 속성입니다.페이지가 ‘호출될 때마다’ 데이터 fetch 와 서버사이드 rendering 이 발생합니다.Static First, Dynamic as NeededSSG 와 CSR 이 유연하게 혼용되는 페이지입니다.예를 들어, /posts/[id]/page.tsx 페이지가, , , , 자식 컴포넌트들을 포함하고 있을 때, page.tsx 와 , 는 RSC React Server Component 로 구성하고, 는 RCC React Client Component 로 구성하는 방식이죠.이렇게 되면, /posts/[id]/page.tsx 페이지는 다이내믹 [id] 에 해당하는 전체 Static 페이지들을 생성하게 되는데, 이 각각의 페이지들이 RCC 인, 를 포함하게 됩니다.그리고, 는, 클라이언트 사이드에서 필요한 최신의 Data 를 불러와서 렌더링 해줄 수 있게 됩니다....fetchNextJS 에서 fetch 는 그 용법과 기능이, JS 내장 fetch 와는 조금 다릅니다.JS fetch 에 프로토타입이 추가된 것 같은데요.기본 fetch 에 몇가지 캐싱 관련 옵션들이 추가되고, 캐시가 강력하게 적용됩니다.이 때문에, NextJS 프로젝트에서는 Axios 를 사용할 일이 없습니다.// NextJS 의 fetch const res = await fetch('', { cache: "force-cache", next: { revalidate: 60, },, // 10초마다 데이터를 다시 가져옴 }); // 캐시된 fetch.response 는, revalidate 시간동안 캐시가 사용됩니다. NextJS 의 메타 태그에 필요한 데이터를 준비할 때, fetch 가 중복으로 요청되는 경우가 빈번히 발생하는데요.. fetch 가 강력히 캐싱되기 때문에, 이 문제를 걱정할 필요가 없습니다....이제 본격적으로, Static 문서를 생성하고 소멸시키는 코드를 하나씩 보겠습니다.generateStaticParamsApp Router 에서만 사용할 수 있습니다.NextJS 의 예약 펑션으로, 이 펑션이 리턴하는 데이터는 NextJS 에서 따로 관리됩니다.컴포넌트나 다른 코드에서, generateStaticParams() 를 호출할 필요 없습니다.page.tsx 에서, Static 문서로 생성할 [id] 목록을 generateStaticParams() 에서 Array 로 리턴해주면 됩니다.App Router 의, /page.tsx 에서 generateStaticParams() 를 export 해주면, generateStaticParams() 가 리턴하는 파라메터에 해당하는, 모든 동적 페이지들에 대해서 Static 페이지들이 생성됩니다.// Supabase 에서 쿼리로 받아온 데이터들에 대해, // NextJS App 의 빌드 시점에 static 페이지를 모두 생성합니다. // 여기서 generateStaticParams() 의 역할은, [id] 로 구성된 배열을 리턴하는 것 까지입니다. export async function generateStaticParams() { const { data: posts } = await supabase.from('posts').select('id') return posts?.map(({ id }) => ({ id, })) } 여기서 주의할 점은, dynamic Route 에서 사용되는 [id] parameter 를 사용해야 한다는 점입니다. 다이내믹 라우팅에서는 [id] 를 사용하고 있는데, 다음처럼 ‘name’ 을 사용하면 작동하지 않습니다. 정적 페이지는 생성되지 않을 것입니다.export async function generateStaticParams() { const { data: posts } = await supabase.from('posts').select('id') return posts?.map(({ name}) => ({ name, })) } generateStaticParams() 펑션은, 다이내믹 페이지를 렌더링하는 page.tsx 컴포넌트의, 헤더 부분에서 정의해 줍니다. // /src/app/posts/[id]/page.tsx import supabase from '@/utils/supabase' import { notFound } from 'next/navigation' // posts 테이블의 모든 [id] 를 확보해서 배열로 리턴 // 전체 [id] 배열의 확보가 목적이기 때문에 params 는 사용되지 않았습니다. // 앱의 빌드 시점에 NextJS 가 SSG 를 수행합니다. export async function generateStaticParams() { const { data: posts } = await supabase.from('posts').select(*) return posts?.map(({ id }) => ({id})) } // 각각의 [id] 에 대해서 데이터를 질의해 받아오고 렌더링 합니다. export default async function Post({ params: { id } }: { params: { id: string } }) { const { data: post } = await supabase.from('posts').select().match({ id }).single() if (!post) { notFound() } return

{JSON.stringify(post, null, 2)}

} 직관적인 이해가 좀 난해한 면이 있긴 한데요.. 빌드 시점에 generateStaticParams() 가 트리거 되면서, Array([id]) 에 대한 loop 가 발동되어서, 를 실행한다고 이해하면 될 것 같습니다.예제 코드를 하나 더 보죠. slug 는 블로그 글 등에서 사용하는, ‘제목’ 을 key 로 하는 데이터베이스 사용 방식입니다. [id] 보다 [slug] 를 사용하게 되는 상황이 더러 있습니다.// // 실제로 사용되는 방식.. // [slug] 파라메터가 사용되는 다이내믹 라우팅 페이지들의 SSG 를 선언합니다. export async function generateStaticParams() { const { data: posts } = await supabase.from('posts').select(*) return posts.map((post) => ({ slug: post.slug, })) } // 주어진 slug 에 대해 개별 데이터를 쿼리하고 리턴하는 펑션 async function getPost(slug) { const { data: posts, error } = await supabase.from('posts').select(*).eq('slug', slug) if (error) return undefined return posts } // slug 페이지 렌더링 export default async function Page({ params }) { const { slug } = params const post = await getPost(slug) // 404 page if (!post) notFound() return (

{post.title}

Author: {post.author}

Published on: {new Date(post.publishDate).toLocaleDateString()}

) } // Optional: SEO 를 위한 Meta data, title export async function generateMetadata({ params }) { const post = await getPost(params.slug) return { title: post?.title, description: post?.excerpt } } export const revalidate = 600; // ISR: 10분마다 페이지를 재생성 generateStaticParams() 로, SSG 대상 [slug] 들의 어레이를 확보합니다.generateStaticParams() 가 리턴하는 어레이가 유효하다면, 해당 어레이에 대해서 SSG 문서가 생성될 것입니다.default async function Page 컴포넌트는 각 문서의 렌더링 만을 담당합니다.NextJS 의 App 이 빌드되는 시점에, generateStaticParams() 가 리턴한 어레이에 대해서 default async function Page 컴포넌트가 하나씩 차례로 실행되고 렌더링 됩니다.렌더링이 완료된 Static 문서가 서버에 저장됩니다.revalidate 는 static 페이지가 생성될 page.tsx 에서 export 해주면 됩니다.revalidate 가 사용되면, ISR 이 적용되며 해당 시간동안 정적 페이지가 활성화되고, 시간이 지나면 다시 재생성 됩니다.generateStaticParams 세 줄 요약.generateStaticParams() 펑션이 리턴하는 파라메터를 사용하는 모든 동적 페이지들에 대해 Static 페이지가 생성된다.page.tsx 에서만 사용할 수 있다.page.tsx 의 디폴트 컴포넌트를 호출하는 iteration 이 생성된다....getStaticProps,Pages Router 전용입니다.getStaticProps() 펑션이 먼저 BackEnd 로부터 데이터를 가져오고, 가져온 데이터를 page.tsx 에게 프롭으로 전달해줍니다.그러나 getStaticProps() 만으로는, 동적 페이지들의 파라메터를 확보하지 못합니다. 때문에 getStaticPaths() 와 함께 사용됩니다.getStaticPaths() 는, generateStaticParams() 와 같은 기능을 한다고 이해하시면 되겠습니다.아래는 getStaticProps가 데이터를 가져오고, 이를 페이지 컴포넌트에 props로 전달하는 예시입니다:// // pages/posts/[id].tsx import { GetStaticProps, GetStaticPaths } from 'next'; import supabase from '@/utils/supabase'; // Supabase 인스턴스를 임포트 // `getStaticPaths`에서 모든 데이터를 가져와서 경로를 설정 export const getStaticPaths: GetStaticPaths = async () => { // 모든 데이터를 한 번에 가져옵니다. const { data: posts } = await supabase.from('posts').select('*'); const paths = posts.map((post) => ({ params: { id: post.id.toString() }, })); return { paths, // paths 에 포함되는 모든 url 에 static 페이지가 생성됩니다. fallback: false, // 미리 정의된 경로로만 페이지를 생성합니다. }; }; // `getStaticProps`에서 특정 데이터만 필터링 export const getStaticProps: GetStaticProps = async ({ params }) => { // 데이터베이스에서 직접 특정 포스트 데이터를 가져옵니다. const { data: post, error } = await supabase .from('posts') .select('*') .eq('id', params?.id) .single(); if (error) { console.error(error); return { notFound: true, // 데이터가 없는 경우 404 페이지로 이동 }; } return { props: { post }, }; }; // 페이지 컴포넌트 // post 는 getStaticProps 로부터 공급받습니다. export default function Post({ post }) { return (

{post.title}

{post.body}

); } ...getStaticPathsPages Router 전용입니다.generateStaticParams() 와 같습니다만, generateStaticParams() 가 dynamic Route 의 [id] 파라메터를 기준으로 static 페이지들을 생성한다면, getStaticPaths() 는 path 라는 이름의 배열을 리턴합니다. 그 형식은 아래 코드와 같고,경로만을 설정하기 때문에, data fetch 를 getStaticProps() 등에서 처리해줘야만 합니다.export async function getStaticPaths() { return { paths: [ { params: { id: "1" } }, { params: { id: "2" } }, ], fallback: true, }; } ..getStaticProps() , getStaticPaths() 두 줄 요약pages Router 방식에서 사용하던 SSG 메서드임. 그런게 있다고 알고만 있자.App Router 에서는 generateStaticParams() 를 사용하면 된다....revalidatePathApp Router 에서만 사용할 수 있습니다.특정 경로에 대해 업데이트 이벤트가 발생하였을 때, 해당 경로 Static 페이지들에 대해 각각의 data 를 새로 받아와서 렌더링하고 재생성합니다. import { revalidatePath } from 'next/cache'; export default async function handler(req, res) { await revalidatePath('/posts'); // '/posts' 경로의 모든 Static 을 다시 생성 res.json({ revalidated: true }); } // 이 코드는, '/posts' 의 모든 SSG, ISR Static 페이지들을 재생성합니다. 특정한 한 개의 페이지를 revalidate 해줘야 할 필요도 있죠.예를 들어, 사용자가 자신의 포스트, /posts/27 을 수정, 업데이트 하는 이벤트가 발생했을 때,await revalidatePath('/posts/27');이렇게 업데이트 코드 밑에 추가해주면 되겠죠....revalidateTagApp Router 에서만 사용할 수 있습니다.revalidatePath 가 경로를 기준으로 refresh 해준다면, revalidateTag 는 태그 [#tag] 를 기준으로 refresh 해줍니다.How to deal with tagstags 는, page.tsx 의 전역 레벨에서 export 해주면 NextJS 에서 이를 인덱싱하고 관리합니다.페이지의 성격이나 분류에 어울리는 tags 를 배열로 할당해주면 이를 기준으로 revalidateTag() 를 사용할 수 있습니다. export const generateStaticParams = async () => { const { data: posts } = await supabase.from('posts').select('*'); return posts.map((post) => ({ id: post.id.toString(), })); }; export default async function Post({ params }: { params: { id: string } }) { const { data: post } = await supabase.from('posts').select('*').eq("id", params.id).single(); return (

{post.title}

{post.body}

); } export const revalidate = 60; // 기본 재검증 간격 export const tags = ['posts', 'food', 'fruits']; // 이 페이지에 대한 태그 설정 import { revalidateTag } from 'next/cache'; import supabase from '@/utils/supabase'; export async function updateFruitPost(postId: string, newData: { title: string }) { // 데이터베이스 업데이트 await supabase.from('posts').update(newData).eq('id', postId); // 'fruits' 태그가 있는 모든 페이지의 static 문서를 무효화하고 재생성 revalidateTag('fruits'); } 편리하긴 할 것 같은데, Tag 관리 정책이 따로 필요할 것 같습니다....fallback & revalidatefallbackfallback 은, pages Router 방식의 getStaticPaths() 의 return 에 옵션으로 추가해줍니다.App Router 와 generateStaticParams() 에서는 사용하지 않고, 라우터의 처리에 맡깁니다.revalidaterevalidate 역시 pages Router 의 getStaticPaths() 펑션에서 사용합니다.App Router 와 generateStaticParams() 에서는,export const revalidate = 600; // ISR: 10분마다 페이지를 재생성 이렇게 사용하고, getStaticPaths() 에서는,export async function getStaticPaths() { return { paths: [ { params: { id: "1" } }, { params: { id: "2" } }, ], fallback: true, revalidate: 600, }; } 이렇게 사용합니다....Static & Dynamic 혼합 구성page.tsx 는 자식 컴포넌트를 여럿 갖게 되는 게 일반적이죠.그런데, page.tsx 의 자식 컴포넌트가 AAA, BBB, CCC 이렇게 있고,page.tsx 를 SSG, ISR 로 렌더링 해준다고 가정해보죠.그리고, 이 중 CCC 컴포넌트가 Comment 컴포넌트 처럼, 데이터 업데이트 주기가 무척 빠르다면, 어떻게 해줘야 할까요?page.tsx 를 SSG, ISR 로 렌더링 해주면, 자식 컴포넌트인 AAA, BBB, CCC 가 모두 Static 으로 굳어진 채 생성됩니다. page.tsx 가 revalidate 되기 전에는 CCC 의 업데이트된 데이터가 출력에 반영되지 못하는 결과가 발생하겠죠.이럴 때, CCC 컴포넌트를 RCC React Client Component 로 만들어줄 수 있습니다. // 'aaa'와 'bbb'는 서버 컴포넌트로, 자주 업데이트되지 않는 데이터 import AAA from './aaa'; import BBB from './bbb'; // 'ccc'는 클라이언트 컴포넌트로, 자주 업데이트되는 데이터 import CCC from './ccc'; export const revalidate = 60; // ISR을 사용하여 페이지를 60초마다 다시 생성 export const tags = ['posts', 'ccc']; // ccc 컴포넌트가 업데이트되면 이 태그를 무효화 // SSG Static 생성 export generateStaticParams() { const posts= await getPostsData(); return posts?.map(({ id }) => ({ id, })) } export default function Post({ params }: { params: { id: string } }) { return (

{/* 정적 컴포넌트 */} {/* 동적 컴포넌트 */}

); } // app/posts/[id]/ccc.tsx 'use client'; import React, { useEffect, useState } from 'react'; type Comment = { id: number; text: string; }; export default function CCC({ postId }: { postId: string }) { const [comments, setComments] = useState([]); const [loading, setLoading] = useState(true); useEffect(() => { // 클라이언트에서 데이터를 가져옵니다. async function fetchComments() { try { const { data } = await getCommentAction(postId) setComments(data); } catch (error) { console.error('Failed to fetch comments:', error); } finally { setLoading(false); } } fetchComments(); }, [postId]); if (loading) return

Loading comments...

; return (

Comments

{comments.length > 0 ? (

{comment.text}

) : (

No comments yet.

)}

); } 한 줄 요약RSC, SSG, SSR, RCC …. RRR, CCC, SSS, GGG, CCCC 를 유연하게 사용하자.

장독깨기 · Answer

아,...브라우저가 html, css, js 등등을 어케 해석해서 화면에 보여주는지,즉, 브라우저가 실제 렌더링 하는 과정을 우리는 알지 못 하고 알 필요도 없습니다.이걸 알려면 크로미움 소스를 분석해봐야겠죠.csr, ssr 에서 렌더링은 html 문서를 어디서 만드느냐 딱 이 관점입니다.ssr 은 서버에서 html 을 만들어서 브라우저에 전송하는 겁니다.csr 은 서버에서 데이터(json)만 받아와서, 자바스크립트로 저 데이터를 기반으로 html 문서를 만드는 것이구요.결론에서 보면,서버에 위임하므로 클라이언트는 랜더링 부하를 줄일 수 있고,이 부분은 완전 말이 안되는 내용이구요,서버에서는 CSR에 비해 오버헤드가 발생하며,데이터만 전송하는 것과 데이터를 포함한 html 을 생성해서 전송하는 것이니, 아무래도 차이는 나겠죠.그래서, 이 부분은 굳이 따지자면 그렇긴 합니다만, 그렇게 중요한 부분은 아닙니다.그리고, 빈번한 통신은 csr, ssr 과 적합하고 말고 이런 것과 아무런 상관 관계가 없습니다.csr 은 브라우저내 ajax 같은 걸로 서버에서 데이터를 받아와 화면을 재구성하는 것이니,화면이 전환되지 않습니다. 이걸 한페이지로 만든 것이 spa 이구요,ssr 은 화면 전환이 이루어지는 겁니다. 브라우저가 요청하면 서버는 html 을 반환하죠.주소에서 url 을 입력해도 그렇고, 링크를 클릭해 다른 페이지로 이동할 때도 그렇고 등등도 그렇습니다.csr 과 ssr 은 딱 이 차이점입니다.csr 을 할지 ssr 을 할 지는 이 차이점을 인지하고,내가 만들 어플리케이션이 어떤게 더 나을지 생각해서 결정하면 될 일 입니다.가령, 여기 오키는 기본적으로 ssr 입니다. 그리고, 부분적으로 csr 이 포함되어 있을 겁니다.https://www.erdspace.com erd 편집 툴인데요, 이건 완전 csr 이고 spa 입니다.자료 만드신다 고생하셨는데요, 내용이 좀 어색한 부분이 많아서요, 오지랖 좀 부려봤습니다.참고 하시고, 자세한건 검색해서 한 번 알아보는게 좋겠습니다. :)

풍월상신(가니메디안) · Answer

Q.내용 감사합니다 정적페이지도 여러개가 존재하는군요 궁금한점은 getSeversideProps와 같은 서버함수를 사용하지 않는다면 기본적으로 next.js는 정적페이지로 빌드시점에 생성되는게 맞나요?A.정 반대죠. 디폴트 비헤이비어는 SSR 이고, SSG 펑션코드가 추가되는 순간, 여러가지 스태틱 모델이 적용됩니다.--------------------- 개념정리Routings:NextJS 13 이전의 라우팅 방식: pages RouteNextJS 13 이후의 라우팅 방식: App Route* 이전이후 태클금지!!SSG Functions:getSeversideProps(), getStaticProps(), getStaticPaths() <-- 모두 pages RoutegenerateStaticParams() <-- App route* 레거시 코드를 만질 일이 없다면 pages Route 펑션은 무시해도 됨.RSC, SSR, SSG 의 차이점:RSC 를 그대로 놔두면 SSR, RSC 에 SSG 펑션 코드를 추가해주면 SSG 가 된다.Principles:1. 모든 NextJS 컴포넌트는 디폴트로 RSC 이다. 즉 디폴트 SSR2. RSC page.tsx 에 펑션과 옵션 몇 라인을 추가해 줌으로, SSG, ISR, DSG, ODR, SSR 변신이 가능하다!!!3. 당연히, 이 모두는 Dynamic Route 에 해당하는 이야기다.

또닉 · Answer

SSR이 별게 아녜요 20년전 php 의 기술이죠. 그냥 Dom을 서버에서 조건에따라 동적으로 만드는거죠.static 이란 개념은 상대적으로 그때 분류된거라 동적으로 서버코드로 다르게 렌더링 못할뿐 html dom을 응답하는 건 같습니다.렌더링(화면에 그림)은 모두 클라이언트(웹브라우저)가 합니다. 그러니 엄밀히 따지면 SSR/CSR의 R은 틀린말입니다. CSR은 주요 컴포넌트 DOM을 자바스크립트에서 만드는거죠. 이제와서 CSR/SSR이라는 구분이 나온건 그간 유행한 JS기술스택 (리액트)등이 그동안 http응답에 dom이 div 하나 빼곤 없어서 였고 웹브라우저로 오고나서야 가상돔을 만드니까 SEO에 불리하다보니 결국 php처럼 http응답에서부터 dom을 받는 기술의 필요성때문에 추가된것뿐입니다. SEO가 중요하면 SSR 하면되고 아니면 아무거나 하세요.

풍월상신(가니메디안) · Answer

바이트 제한으로 자꾸 새댓글을 달게 됩니다. 오키 바보Q.아하 페이지 라우터랑 앱라우터에서 차이가 발생하는군요페이지라우터에서는 특별한 서버함수만 요청시에 서버에서 실행됬는데 앱라우터에서는기본적으로 모든 컴포넌트가 서버컴포넌트로 동작한다.그렇다고해도 여전히 useEffect와 같은 후크는 클라이언트에서 실행되므로빈번한 통신이 필요한경우 앱라우터든 페이지라우터든 ssg,ssr,csr 상관없다는 주장은 문제가 없을까요?A.NextJS 에서 모든 디폴트 컴포넌트가 RSC 로 작동하기 시작한 건 꽤 오래 된 것으로 압니다. 적어도 13 이전으로 알아요. 그리고 RSC 는 모두 디폴트 SSR 입니다. SSG 코드가 삽입되면 여러 베리에이션으로 SSG 가 됩니다.그리고, '빈번한 통신' 이 정확히 어떤 의미인지는 모르겠습니다만,댓글이나 채팅 처럼, '최신' 의 데이터를 의미한 것이라면, static 으로도 원하는 바를 충분히 해결할 수 있습니다.제가 가장 중요하다고 생각하는 부분이기도 한데요,Static 에서도 RCC React Client Component 를 자식 컴포넌트로 품을 수 있다는 것입니다.RCC 는 일반 React 컴포넌트 처럼, 클라이언트 단에서 백엔드의 data 를 fetch 해서 사용자에게 렌더링해줄 수 있습니다. 쇼핑몰의 1만개의 페이지가 Static 으로 빌드 되었는데, 클라이언트 단에서 최근의 QnA 와 Testimonials 를 fetch 해와서 렌더링 해줄 수 있다고 생각해보세요. 어메이징하지 않습니까? React Hook 은 오직 RCC 에서만 사용할 수 있습니다. 브라우저단의 '상태' 를 다루기 때문이죠. RSC 에서는 불러올 수도 없어요.그리고, '빈번한 통신' 이 서버 자원과 비용을 고려한 개념이었다면, static 이 우선 고려되어야 할 것이고요.하지만 말씀드렸듯이, 문서/컴포넌트의 렌더링 위치와 시점에 관계 없이 RCC 를 자식으로 품을 수 있다는 점은 무한한 가능성을 열어줍니다. '빈번한 통신' 이 서버자원을 고려한 개념이든, 최신의 데이터를 고려한 개념이든, 어떤 경우에도 SSG+RCC 는 최소한의 서버자원 소모로 최신의 데이터를 사용자에게 제공할 수 있으니까요.관심과 시간을, SSG+RCC 에도 투자해보는 게 좋지 않을까 생각합니다.

제가 알고있는 ssr의 장점이 맞는지 궁금합니다

7개의 답변

기술 목록