Next 와 React

Next 강의를 들으면서 Next를 잘 다루려면 Next를 본문을 많이 읽어봐야겠다는 생각이 들어
이번에 Next 본문을 읽으면서 React도 좀 더 자세하게 파헤쳐봐야겠다는 결론으로  
Next를 쓰는 이유에 대해서 알아보았다.

Next 공식 문서 링크 : https://nextjs.org/

Next.js by Vercel - The React Framework

React 공식 문서 링크 : https://ko.legacy.reactjs.org/

React – 사용자 인터페이스를 만들기 위한 JavaScript 라이브러리

처음 페이지에 들어가면 리액트 사용자 인터페이스를 만들기 위한 자바스크립트 라이브러리 이며

넥스트는 React를 사용하는 프레임 워크로 React 기능을 확장하여 사용할 수 있다고 한다.

 

라이브러리 vs 프레임 워크

 프레임워크와 라이브러리의 가장 큰 차이점은 "제어 흐름"이 어디에 있는가이다.  

프레임 워크는

원하는 기능 구현에 집중하여 개발할 수 있도록 일정한 형태와
필요한 기능을 갖추고 있는 뼈대를 의미하고 

라이브러리는

컴퓨터 프로그램이 사용하는 비휘발성 자원의 모임. 즉 특정 기능을 모와둔 코드,
함수들의 집합이며 코드 작성 시 활용 가능한 도구들을 의미하는 것이라고 이해하고 있었다.

 

정확히는 라이브러리는 애플리케이션의 코드의 흐름을 직접 제어해야 하며
라이브러리를 호출하여 기존에 구성 구성된 함수나 코드를 가져다 써야 하며 

프레임워크는 애플리케이션 코드가 프레임워크에 의해 사용되며
프레임워크가 짜 놓은 틀에서 수동적으로 동작하기 때문에 제어의 흐름은 프레임워크가 가지고 있고
  여기서 제어의 역전이란 것이 등장한다.

프로그래머가 직접 객체의 생성과 소멸 객체 간 관계 같은 객체의 제어를 수행하는 것이 아니라,
여러  프레임워크, 컨테이너에서 제어를 수행하는 것이라고 한다.

 

정리하자면 리액트는 도구를 제공해 주고 넥스트는 틀 안에서 코드를 작성해 주면 넥스트가 처리해 준다!

 

SPA (Single Page application)

리액트는 공식 문서에 나와있는 데로 싱글 페이지 애플리케이션(SPA)이다.

• 한 개(Single)의 Page로 구성된 Application이다.
• SPA는 CSR(Client Side Rendering) 방식으로 렌더링 한다.
• 단 한 번만 리소스(HTML, CSS, JavaScript)를 로딩한다.
  그 후에는 데이터를 받아올 때만 서버와 통신한다.
  즉, 첫 요청 시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식이다.

이를 클라이언트 관점에서 말하자면 최초 페이지를 로딩한 시점부터는
페이지 리로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신한다.

SPA 단점

1. JavaScript 파일을 번들링 해서 한 번에 받기 때문에 초기 구동 속도가 느리다.
   (Webpack의 code splitting으로 해결 가능)
2. 검색엔진 최적화(SEO)가 어려움 (SSR로 해결 가능)
3. 보안 이슈 (프런트엔드에 비즈니스 로직 최소화)
   • SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트 측의 쿠키 말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다

 

이것으로 보아 리액트의 SPA는 클라이언트 사이드 렌더링(CSR)으로 동작한다는 결론이다.

그럼 넥스트는 서버사이드 렌더링이잖아  라고 하기전에 공부할 겸 CSR과 SSR은

CSR 은 렌더링이 클라이언트 쪽에서 일어나며
SSR 은 렌더링은 서버 쪽에서 일어난다.

CSR은  서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내주면.클라이언트는 그것을 받아 렌더링을 시작하는데 자바스립트가 모두 다운로드되고 실행이 끝나기 전까지 사용자는 볼 수 있는 게 없다.

 

SSR은 서버 쪽에서 렌더링 준비를 끝마친 상태로 클라이언트 쪽에 보낸다 이전에 HTML 파일은 미리 렌더링 되어있기 때문에 화면단은 빠르게 보여줄 수 있지만 자바스크립트 파일이 다운로드되지 않았다면
동작할 수 없다.

 

CSR 장점

• 초기 로드만 완료되면 이후 렌더링이 빠르다.
• 서버에 요청할 것이 거의 없어 서버 부담이 적다. (data 필요할 때만 요청)
• Web Applications에 좋다.

 

CSR 단점

• SEO에 좋지 않다. (초기 HTML 파일이 비어있기 때문에 봇이 데이터 수집하기 어려움)
• 초기 로드가 오래 걸린다. 
• 외부 라이브러리가 필요한 경우가 많다.

 

SSR 장점

• SEO에 좋다. (HTML 파일에 모든 정보가 포함되어 있기 때문에 봇이 데이터 수집 가능)
• 초기 로딩 속도가 빠르다.
• Static sites에 좋다.

 

SSR 단점

• 서버에서 전체 앱을 미리 렌더링 하기 때문에 컴포넌트 로딩이 오래 걸리면 유저는 빈 화면을 볼 수도 있다. 
• 서버에 매번 요청하기 때문에 서버 부하가 크다. (view 변경 시 요청)
• 페이지를 요청할 때마다 새로고침되어 UX가 다소 떨어진다.

그래서 NEXT는 서버사이드 렌더링이라는 말은 많이 들어서 그러려니 하고 있었는데
그 이유에 대해서는 정확히 알지 못했다.

 

이 흥미로운 부분을 발견했다. 첫 줄에서 React의 api를 사용하여 렌더링을 오케스트레이션 한다고 한다.

즉 Next가 React의 기능을 가져가다가 서버에서 실행 후에  UI를 구성한 후
그렇게 렌더링 된 HTML 파일을 클라이언트에게  제공하는 것 같다!

하 번역기 무슨 일? 진짜 영어도 공부해야 되나 

결론으로 NEXT 가 SSR인 이유는 NEXT 서버에서 React의 API를 실행 후 렌더링된
HTML 파일을 클라이언트에게 제공하는 것이므로 이해를 하면 되겠다?! 
NEXT의 동작원리에 대해서는 아직 좀 더 본문을 살펴봐야겠지만
공식 링크를 많이 둘러보지 않았었는데 이번 공부로 반성하는 계기가 되었던 것 같다.