여태까지 yarn dev해서 우리컴퓨터에서 봤지만
따로 서버로 쓸 컴퓨터를 쓰거나 만들어서 yarn dev를 시켜놓고 거기에 접속하면 된다.
근데 결정된 서버를 초과하는 사람들이 들어오면 서버를 늘려야하는데 서버 늘리는게 하루이틀안에 되는게 아니다 -> 그럼 우리가 빌려줄께! 원격으로 우리 컴퓨터 빌려줄께, (클라우드) AWS, GCP, Azure 이런 서비스들이 등장했다 이렇게 빌려서 쓰면 돈 내고 바로바로 늘려서 쓸 수 있게 되는거다
마우스 클릭으로도 배포가 가능해진것 (매크로, 코드만 배포가됐다)
원래는 배포하는 사람이 따로있었다 코드 완성해서 주는 개발자 - > 배포자(장애를 확인, 네트워크 지식이 필요)
하지만 클라우드가 더 진전되면서 쉽게 배포가 되기 때문에 개발자가 배포 + 운영 까지함 -> Development Operarions
여기서 Dev-Ops가 나오게된것 (만약 서비스가 커지면 팀으로 변한다)
SSR Server Side Rendering 서버사이드 렌더링
오픈그래프
네이버의 개발자도구 - 콘솔 - 헤드부분을 보면 og라는 걸 볼 수 있다.
특정한 주소를 입력했을 때 미리보기를 제공하기 위한 부분이다
페이스북에서 시작한것으로 이걸로 미리보기기능만들어보자 해서 만들었음
-> 너도나도 쓰면서 표준이 되었다.
-> 암묵적으로 슬랙, 카카오톡에도 주소를 쓰면 (axios: naver.com )그럼 가져오다가 META부분을 찾아서 og부분을 찾고 거기있는 타이틀, 이미지를 찾아서 보여준다
-> 우리는 그냥 미리 보기 처럼 보임
트위터: 카드형식으로도 있지만 페북에서 만든 og가 유명함
이런걸 스크래핑이라한다
블로그, 메신저, 등등에서 이런 기능은 많이 쓰인다.
이게 이제 서버사이드렌더링이랑 뭔관계냐?
axios.get으로 받아오는 데이터에는 useQuery이런거까지 요청해서 가져오지 않는다
데이터는 걍 비어있는셈
여기서 차이점이 생긴다
상품 상세페이지(API를 써야되는 부분)까지 오픈그래프를 적용하고 싶다 - 이러면
브라우저에서 엔터 - 프런트엔드 가서 html,javascript만 가져오는게 아니라 useQuery등등까지 실행시켜서 완성형으로 가져와야함
-> 이게 서버쪽에서 그려서 가져온다 - > 서버사이드렌더링이라고함
그럼 모든 페이지를 서버사이드렌더링하면 되는거아닌가?
-> 필요한 페이지 빼고는 기존방슥으로하는게 더 효울적임
기술적인 난이도가 있는 부분이기때문에 큰곳(네이버나 쿠팡)만 된다
서버사이드 렌더링이 되어있을경우 검색엔진의 크롤러 봇에도 잘 노출이 된다. (완성된 형태의 정보까지 저장될 수 있으니까)
++ 근데 구글크롤러봇같은경우는 어느정도 api사용같은건 기다려준다고하는데 다는 못기다려준단다
**
어떻게 구성해야하는가?
DB와 백엔드 하나, ssr을 위한 yarn dev, 그냥 프런트엔드를 위한yarn dev가(SSG, Static Site Generator 정적)필요하다
정적 파일들을 스토리지에 올려놓고 (스토리지가 망가질가능성은 거의 없음, 무한트래픽)
서버사이드 렌더링이 필요없는부분은 이렇게하면된다
서버사이드 렌더링은 로직들을 거쳐야함(usequery같은거, api요청 등등)
그래서 둘이 나눠야한다.
그럼 백엔드와 db하나, 스토리지에 올리는 ssg하나(구글스토리지같은데 올림) 우리가 필요한건 컴퓨터 하나 더에 (혹은 가상머신, vm)에 SSR을 올려야한다.
그럼 이걸 어떤 파일로 가야될지 모를수도있으니까 여기서 로드밸런서가 필요하다
(여기는 SSG, SSR로 가줘 등등) 부하를 분산해주는 개념 뿐만 아니라 다른페이지를 보여주는 역할도 한다.
(VPC는 하나의 네트워크 안에 묶는다고 생각하면 편하다)
++ 보너스 실제 배포할때는 컴퓨터가 3개가 아니라 그의 세배가 필요하다
왜냐??
실제 서비스에서는 실제 서비스가 돌아가고있는 prod, 실제 유저가 사용하는 것과 같은 환경인데 다른 버전을 업그레이드하는데 쓰이는 staging , 그리고 아무 데이터, 실행을 해보는 dev, 그리고나서 우리가 연습해보고있는 local(local host)가 있다.
각각 단계에서 컴 세개씩 쓰고있으니.. 3배인것
배포의 구조
서버사이드 렌더링 ssgssr
배포구조알기
+알고리즘
