전통적인 방법:
브라우저: 페이지 줘!
프론트서버: 백엔드 서버야 데이터 좀 줘 봐
백엔드 서버: 여깄음
프론트 서버에서는 백엔드 서버에서 온 데이터와 html을 합쳐서 브라우저로 보냄
데이터의 흐름이 '브라우저 - 프론트 서버 - 백엔드 서버 - 데이터베이스'와 같이 일자 형태.
리액트, 뷰, 앵귤러를 사용하면...(SPA(CSR))
브라우저: 페이지 줘!
프론트 서버: 여기 빈 화면 받아봐. 데이터는 브라우저 네가 직접 백엔드한테 달라고 해.
브라우저: 일단 데이터 가져오는 동안 로딩 화면 좀 띄워놔야지. 백엔드야 데이터 좀 줘!
백엔드: ㅇㅋ. 여기 데이터베이스에서 가져온 데이터임.
브라우저: 데이터 받았으니까 로딩창 없에고 화면 그려야지.
전통적인 방법은 전체 화면이 한 번에 그려진다는 장점이 있지만, 모든 페이지들을 한 번에 다 가져오기 때문에 로딩 속도가 좀 걸릴 수 있음. 화면이 3초 안에 나오지 않으면 유저가 떠난다고 함. 리액트, 뷰, 앵귤러 같은 것도 데이터를 받아오느라 시간이 오래 걸릴 수 있음. 다만 데이터를 받아오는 동안 로딩창 같은 것이라도 미리 보여줄 수 있다는 것은 장점임.
'무작정 리액트 힙하니까 리액트 쓰자'는 지양해야 한다. 어떤 페이지는 리액트 없이 만드는 것이 나을 수도 있다.
검색 엔진 관련해서는, 구글 검색 엔진은 spa인 것을 알아차리는데 국내 검색 엔진은 '이 사이트는 로딩창 밖에 없나?' 이러고 그냥 사이트를 떠난다고 함.
이 해결법이 ssr과 code splitting. code splitting은 방문한 페이지에 대한 코드만 가져오는 것. ssr도 두 가지 방법이 있음. pre render, 서버 사이드 렌더링. pre render는 검색 엔진인 것을 알아차리고 검색 엔진일 때만 백엔드에서 데이터 받아와서 Html 완성해서 페이지를 주고, 일반 유저일때는 기존 리액트 방식으로 주고. 서버 사이드 렌더링은 첫 방문시에 전통적인 방법으로 하고, 그 다음 방문하는 페이지부터는 리액트 방식으로 하고.
서버 사이드 렌더링, code splitting을 실무에서는 거의 필수로 적용한다고 한다. (엄청 간단한 페이지가 아니고서야) 대부분의 페이지가 검색 엔진에 노출이 되어야 하고, 사용자를 대상으로 하는 페이지는 속도도 빨라야 하기 때문에 code splitting도 적용해야 함.
어드민 페이지처럼 code splitting, ssr이 필요없는 페이지는 react로만 해도 된다. 어드민 페이지가 검색 엔진에 노출되어야 하는 것도 아니고, 관리자들에게 반응 속도가 그렇게 중요하지 않을 것이기 때문. 그러니 3초 안에 페이지를 띄워야 하는 서비스가 아니면 굳이 복잡하게 next로 하지 않아도 된다.
그렇지만 웬만한 b2c 서비스라면 ssr를 지원하는 프레임워크를 고려해 볼만하다.
server side rendering, code splitting 이게 리액트로도 구현 가능하긴 함
