질문입니다.

Link 태그를 누를 때 프론트엔드 서버로 청크를 달라는 요청이 하나 갑니다. 만약 기존에 받은 청크가 있다면 요청 없이 바로 csr이 됩니다. 이 과정을 자동으로 해줘서 마치 next가 csr로 동작하는 것 같은 느낌이 듭니다. 알아서 해주므로 청크나 코드 스플리팅은 코딩 시 신경 안 쓰셔도 되는 부분이고요.

front/server.js 코드는 첫 요청때만 필요합니다. 브라우저 주소창에 localhost:3060/user/3 이렇게 요청을 보내면 그걸 localhost:3060/user?id=3 이렇게 바꿔주는 역할일 뿐입니다. 그 외에는 아무 필요 없습니다. 한 번만 사용되는 코드라도 사용자가 많아지면 각 사용자마다 한 번씩은 사용하는 것이므로 프론트엔드 서버도 상당히 많은 요청을 받게 됩니다.

상세하고 친절한 답변 감사드립니다. 조금씩 이해가 되어 가는 것 같습니다. 

'넥스트는 첫 화면만 SSR(프론트 서버 개입)이고 그 다음부터는 CSR이라고 보시면(브라우저-백엔드 간 통신) 됩니다.' 

라고 말씀하셔서 그 부분에 대한 의문을 또 여쭤보고 싶습니다.

1. 첫 화면만 프론트 서버가 개입하고 그 후엔 청크정도만 주는 것이 역할의 전부라고 하셨습니다. 그러면 첫 화면 이후엔 벡엔드하고만 통신을 한다는 것인데 코드 스플리팅에 대한 요구는 어떻게 프론트 엔드 서버가 알 수가 있죠? 완전히 다른 페이지로 넘어갈 때 또 다시 그때만 프론트 엔드 서버에 접속하여 관련된 코드 스플리팅된 js를 얻어오는 건가요? 

2. '브라우저에서 Link 태그를 눌러도 프런트서버로 요청이 가는게 아니라 csr로 계속 동작하는 것입니다.' 에 대한 질문입니다.

Front\server.js 에 있는 모든 코드들은 프론트 엔드 서버안에서 돌아가는 코드니까 첫 화면 로딩 후 브라우저가 요청을 하지 않는 것이니 첫 화면 로딩 후 무쓸모한 코드가 될 것 같습니다. 

위와 같은 코드들은 프론트 엔드 서버에 접속해야만 반응하는 기능들일 텐데 브라우저는 어짜피 첫 화면만 받은 후에 말씀하신대로 벡엔드하고만 대화를 할테니까요. 저는 강의를 들으면서 

'아 서버라는 것은 get과 post와 같은 api 호출을 브라우저를 통해서 받고 이에 적절한 데이터로써 화답하는 것이구나' 라 생각했는데 브라우저에서 호출도 안하고 관심도 없다고 하니 저 코드의 존재 의미가 뭔지 이해가 안가네요.. 

저 코드는 초기 ssr할 때에만 사용하는 코드인가요? 동적 라우팅을 돕는다는 설명으로는 저한테 이해가 안가네요..

읽어주셔서 감사합니다.

강의 중간에 프론트에 요청을 보내면 app.render때문에 리로딩이 되기때문에 위 코드로 요청을 보내지 않는다고 하고 Link태그의 속성을 수정하셨습니다.

제가 이렇게 말을 했나요? 브라우저에서 프론트엔드 서버로 요청을 보내면 보통 문제가 발생합니다. 백엔드서버로만 요청을 보내야 합니다.

처음 SSR이 된 후에는 Next는 CSR로 동작합니다. 브라우저에서 Link 태그를 눌러도 프런트서버로 요청이 가는게 아니라 csr로 계속 동작하는 것입니다. 브라우저에서 axios로 /user/:id/posts를 요청하면 바로 백엔드로 요청이 갑니다. 프론트엔드 서버는 아무런 일도 하지 않습니다. (굳이 하나 한다고 하면 코드스플리팅된 청크 보내주는 정도)

넥스트는 첫 화면만 SSR(프론트 서버 개입)이고 그 다음부터는 CSR이라고 보시면(브라우저-백엔드 간 통신) 됩니다.

답변 감사드립니다. 

답변의 윗 부분은 이해가 갔으나 본 프로젝트에서 Next가 작동되는 원리에 대해서는 절차에 대해서 이해가 가질 않습니다.. 

웹 페이지 초기 접속 후, 홍길동이라는 해시태그를 클릭해서 해시태그를 가진 게시글들을 모조리 불러오는 페이지를 렌더링하기까지 과정을 말로 설명한다고 가정하겠습니다. 

=============================================

현재 프론트 엔드 서버(express with next) , 벡엔드 서버( express ) 가 돌아가고 있음

(웹 페이지 초기 접속 ) 

1. 웹 브라우저는 URL로써 프론트 엔드 서버에 요청 

2. 프론트 엔드 서버는 해당 요청에 맞는 데이터까지 벡 엔드에서 다 긁어 온 후에, 완성된 형태의 HTML 문자열과 해당 하는 화면에 대한 코드 스플리팅 된 JS를 브라우저에 전달.

3. 브라우저는 SSR된 HTML 문자열과 JS를 다운로드 받고, HTML을 렌더링 하여 사용자에게 보여줌

( 여기까지가 웹 페이지 초기 접속 끝,

이제부턴 CSR적용? ) 

4. 그 후 원하는 해시태그를 클릭

5. 브라우저는 user/:id/posts 와 같은 형태를 백 엔드 서버에 요청해서 받아오기

5번에서 이해가 안갑니다. next(버젼 8기준)가 동적 라우팅이 안되서 express위에다 돌렸다고 했는데, 그래서 아래 코드와 같은 것을 쓴 것 이죠. 

그런데 강의 중간에 프론트에 요청을 보내면 app.render때문에 리로딩이 되기때문에 위 코드로 요청을 보내지 않는다고 하고 Link태그의 속성을 수정하셨습니다. 이게 무슨 소리인지 이해가 안갑니다. 동적 라우팅을 하기위해서 그 통로로써 이 부분이 존재하는 것 아닌가요..? 저는 당연히 브라우저에서 user/:id/posts를 요청하면 당연히 이 곳을 거쳐야 한다고 생각을 합니다. 아니 그냥 NEXT의 전체적인 순서가 이해가 안가는 것 같습니다.SSR CSR 각각은 이해가 가려는데 하이브리드에 동적 라우팅이런 주제랑 섞이니 기존의 지식이랑 연동이 안되는 것 같네요.. 

조금 만 더 설명을 해주실 수 있을 까요? 

감사합니다.

일단 그림이 모두 틀렸습니다. 기본적인 전제는, 맨 처음 브라우저는 html만 해석해서 화면에 렌더링하고 이미지, js, css, 동영상, 폰트 등은 그 다음에 요청해서 렌더링합니다.

또한 용어에서 서버쪽에서 렌더링하는 것은 html 문자열을 만드는 것이고 브라우저의 렌더링은 화면에 표시하는 것을 말합니다.

CSR은 일단 요청이 프론트 서버로 (예시 /post/1) 한 번 갑니다. 그러면 프론트 서버에서 post에 대한 화면만 렌더링해서 html로 만들어 내려줍니다. 브라우저는 화면만 받아서 렌더링하고 비어있는 데이터에 대한 요청(/api/post/1)을 한 번 더 백엔드 서버로 보냅니다. 그러면 백엔드에서 데이터를 json으로 내려보내주고 그걸 브라우저가 렌더링합니다.

SSR은 일단 요청이 프론트 서버로 (예시 /post/1) 한 번 갑니다. 그러면 프론트 서버에서 백엔드 서버에 post에 대한 데이터(/api/post/1)을 요청하고 결과를 받아서 화면과 조합한 html 문자열을 만들어냅니다. 그걸 브라우저가 받아 렌더링합니다.

CSR의 단점은 백엔드 데이터를 한 번 더 받아와야해서 로딩 창이 뜨는 것이고, 장점은 화면 렌더링 시간은 더 빠르기때문에 고객 경험이 좋은 것입니다.

Next는 첫 접근만 SSR이고 그 다음부터는 CSR로 하이브리드 방식입니다. 이건 SSR, CSR과 상관없긴 한데 SPA는 처음에 모든 화면에 대한 JS를 내려받습니다. 이게 용량이 크기 때문에 코드 스플리팅을 하는거고요. 그러면 화면별로 js가 나뉩니다. 거기서 chunk.js들이 생성됩니다. 또한 html은 처음 한 번만 필요합니다. 그 후에는 js가 화면을 컨트롤하니까요. css도 js가 컨트롤합니다.