[인프런] Nodebird 리뉴얼 이론 - Next

다 까먹어서 리뉴얼 강좌로 다시 시작 // 

 

Next? 

리액트로 만든 프레임워크. 실무에 필요한 여러가지를 해줌. SSR, CS, prefetch같은 것들. 

고객대상 페이지라면 고려해볼 프레임웤. 

 

 

원리!

1) SSR방식 

Server Side Rendering

전통적인 방식

 

플로우:

브라우저(.com/blog 페이지 요청) - 프론트 서버(/posts의 게시글 요청) - 백엔드 서버(DB에 실제 게시글 데이터 요청) - 데이터베이스 - 백엔드 서버 - 프론트 서버 (데이터+html을 합쳐서 브라우저에 보내줌) - 브라우저(출력)

 

브->프->백->데->백->프(html+data)->브

 

장 단?

전체가 한방에 그려진다는 장점이 있지만, 과정이 길어 로딩속도가 오래걸린다. 

3초 이내 화면이 보이지 않으면 사용자가 떠나요. 로딩창이라도 보여줘야 해요. 

 

 

2) SPA방식 CSR

Single Page Application 브라우저가 프론트와 서버에 요청을 보낸다. 

리액트, 뷰, 앵귤러, 스벨트 : 안에 컴포넌트만 바꿔서 눈속임 해주는 것.

 

플로우:

브라우저 (.com/blog /about 페이지 등 프론트 서버에 요청) -> 프론트 서버 (브라우저에 하나의 js html과 css img를 내려줌. - 화면을 그려주는데 데이터가 없음. -> 데이터가 없기 때문에 로딩창을 띄움 뻉글뺑글)

+

브라우저 (/posts 게시글을 달라고 다시 한번 백엔드에 바로 요청을 보냄) -> 백엔드 서버 (데이터베이스에서 실제 게시글들 받은 다음 바로 브라우저로 넘겨줌. ) -> 브라우저(뺑글뺑글 로딩창 없애고 백엔드서버에서 받은 데이터를 화면에 그려준다. )

 

데이터 없이 화면만 먼저 받고

데이터는 백엔드에서 직접 받아옴. 

 

브->프->브 (여기서 일단 화면 뿌리고 백엔드에서 데이터 뿌릴 시간 벌어준다. )
브->백->데->백->브

장 단?

모든 페이지 - 앞으로 바뀔거에 대한 화면도 다 가져와야 하기 때문에, 데이터까지 받아오는 시간은 더 걸릴 수 있다. (ex. 난 블로그 페이지만 필요한데, about page, admin 페이지까지 다 가져옴. ->코드스플리팅으로 해결)

하지만 로딩창 선 보내주니까 화면에 뭐라도 보이는 시간이 적어서. 이건 장점. 

 

검색엔진:

- Google: 아, 이거 SPA니까 좀만 기다리면 데이터 오겠네. 기다려야지 룰루 

- 다른 엔진: 어? 로딩창밖에 없네! 미완성 사이트구만 나가야지! ->SSR로 해결

 

=> Next의 하이브리드 방식으로 해결(SSR + 코드스플리팅):

- 브라우저를 통해서 첫 방문만 SSR로 해서 검색엔진에 잡히게, 로딩창 없게. (브->프->백->데->백->프(html+data)->브) - 첫 방문 후 다른페이지로 들어갈 때는 (SPA - 링크 , a태그 누를 때) CSR + 코드스플리팅으로 필요한 페이지만 가져오기 . 

 

 

 

넥스트 없이 리액트도(SSR, CS를) 할 수 있긴 하다. https://github.com/reactGo/reactGo 오.. 이거 나중에 봐야지 . 

reactGo/reactGo

 

Next를 언제 쓰고 안쓰고 ? 

Code Splitting, SSR 필요 없을 때: 

ex. Admin페이지. 필요없어. 고객들에게 반응속도가 중요한 것 만큼 관리자에게 필요하지 않아. B2C는 쓰는게 좋다