서버사이드 랜더링 = 타임리프, JSP
클라이언트 사이드 랜더링 = 리액트
우선, 정적 컨텐츠란, HTML css js 파일처럼 항상 똑같은 내용을 불러오는 파일을 말한다.
정적 = 동일한 요청이면 동일한 응답을 한다. (html 껍데기 내용은 항상 같음)
이때 자바스크립트에서 백엔드 서버에 ajax, axios fetch 같은 요청을 하면
백엔드 서버에 게시글 데이터를 동적으로 받아온다.
서버에 존재하는 게시글 데이터는 변할 수 있으므로 동적 컨텐츠라 부른다.
동적 = 동일한 요청이여도 다른 응답을 할 수 있다.
이러한 데이터를 동적 컨텐츠(DB에서 json 형태로 데이터만 받아오는 것)라고 한다.
이제부터는 HTML css js 같은 정적 컨텐츠를 받아오는 것과
서버에서 DB를 거쳐서 json 데이터를 받아오는 동적 컨텐츠 개념을 엄격히 분리해서 생각해야 한다.
서버라는 개념을 다시 강조하면,
클라이언트 (웹브라우저)에서 요청을 해서 파일이나 데이터를 서버로부터 받아오는 것이다.
클라이언트(웹브라우저)는 서버에서 받아온 내용을 화면에 띄워주는 역할을 한다.
위의 방식이 주로 서버 사이드 랜더링에서 사용한다.
1. 브라우저에 URL 주소를 입력하면
2. 백엔드 서버에서 ModelandView 안에 데이터를 담고
3. templates에 존재하는 html(타임리프, jsp)에 Model에 있는 데이터를 꽂아 넣고
4. 브라우저는 최종 결과물을 받아서 브라우저에 띄운다.
즉, 서버측에서 데이터를 html에 넣는 랜더링이 일어난다.
백엔드 서버에 프론트(HTML css js)파일이 같이 존재하며,
클라이언트가 브라우저 주소로 /member/list 을 치면
백엔드 서버에서 화면에 뿌릴 데이터까지 html에 꽂아 넣고 브라우저로 전송해준다.
위의 그림이 지금까지 해왔던 프로젝트 구조이다.
프로젝트에서 /page/* 와 /api/*를 나눈 이유도
정적 컨텐츠(프론트html css js)와 동적 컨텐츠(백엔드 db 데이터)를 구분하기 위함이다.
https://gw7193.tistory.com/m/4
이제부터 클라이언트 사이드 랜더링 방식이다.
먼저, 클라이언트(웹브라우저)에서 프론트서버에서 HTML 같은 정적 컨텐츠를 불러오고,
백엔드 서버에서 json 데이터까지 총 2번 불러오는 것이다.
이제 프론트 서버(html css js만)와 백엔드 서버(DB데이터만)를 완전히 분리한다.
즉, 백엔드 서버가 돌아가는 컴퓨터랑 프론트 서버가 돌아가는 컴퓨터 서로 다른 셈이다.
물론 같은 컴퓨터 내에서 포트 번호만 다르게 해도 다른 서버로 취급한다.
서버를 완전히 분리해도 데이터 요청을 할 때 public 도메인 주소(http://~~)만 잘 맞추어 주면 된다.
위와 같은 구조에서 www.naver.com
을 입력한다고 생각해보자.
1. 웹브라우저에 URL 입력시 먼저 프론트 서버(ex, localhost:3000 , http://111.111.111.111:3000/Project)에서
html css js 정적 컨텐츠를 받아와서 브라우저에 데이터는 없는 html 껍데기만 띄운다.
웹브라우저 ---> 프론트 서버 (요청) ---> 웹브라우저(응답으로 html css js 정적 파일)
2. 웹브라우저에서 1번에서 받아온 정적 컨텐츠 코드를 읽으면서 <script> 자바스크립트가 실행되고, axios , ajax , fetch 같은 요청이 일어나 백엔드 서버로 json 데이터만 요청한다.
(ex, localhost:8080/~~ , http://222.222.222.222:8090/Project/board/list)
(리액트 같은 경우에는 똑같이 jsx --> 자바스크립트로 변환되서 클라이언트로 전송된다.
실제로 웹브라우저에서 받는 건 변환된 자바스크립트 파일)
웹브라우저 ---> 백엔드 서버 (요청) ---> 웹브라우저(응답으로 json 동적 콘텐츠 데이터 )---->HTML 내용 출력
3. 웹브라우저에서 데이터를 받아오면 (ajax : success , fetch axios : then~) html에 데이터를 화면에 꽂아준다.
(ex, $('title').text(item.title) )
이제 배포 과정이다.
Github, 젠킨스 서버가 추가된다.
CI는 지속적 통합(Continuous Integration, CI)
쉽게 말해서 Github에서 젠킨스로 코드가 전송되고 빌드가 일어나고 배포되기 전까지 준비 단계
CD 지속적 배포(Continuous Deployment, CD)
쉽게 말해서 젠킨스에서 이미 빌드가 된 실행가능한 war 파일이 서버로 전송되고 실행까지 되는 배포 단계
백엔드 서버에는 톰캣이 스프링 프로젝트(프론트 파일은 x, json 데이터만 응답)가 돌아가고,
프론트 서버에는 Nodejs 서버가 돌아가고 HTML css js 파일을 응답해주는 역할을 한다.
둘 다 api 주소로 요청을 해서 응답을 받는 방식은 원리는 같다.
예시)
백엔드는 222.222.222.222:8090/member/list 요청을 하면
[
{
"name" : ~,
"phone" : ~,
}
, ...
]
이런식으로 json 데이터를 받고
프론트는 111.111.111.111:3000/productList 로 요청을 하면
제품 목록 화면을 띄워주는 HTML을 응답 받아서 브라우저가 그 HTML css 코드를 화면에 띄운다. + 자바스크립트도 실행
이제, 프론트와 백엔드 Github 레파지토리를 완전히 분리해서 배포해야한다.
백엔드 Github에 main 브랜치에 PUSH를 하면 깃허브 코드가 젠킨스 서버로 전송되고 빌드(CI)된다.
그리고 연속적으로 이어서, 빌드가 되면 실행가능한 war 파일이 만들어지고 백엔드 서버로 실행 파일만 배포(CD)된다.
백엔드 Github ----CI----> 젠킨스 ----CD----> 백엔드 서버
그리고 톰캣이 그 war 실행 파일을 실행하면 배포한 프로젝트가 실행되는 것이다.
마찬가지로, 프론트 Github에도 PUSH 하면 젠킨스에서 빌드(CI)되고
젠킨스에서 프론트 서버로 html css js 파일이 Node.js 서버로 배포(CD)된다.
그러면, 프론트 서버에 Node.js 서버에 요청이 들어오면 html css js 파일을 응답해준다.
프론트 Github --CI---> 젠킨스 ---CD--> 프론트 서버
그리고, 마지막으로 프론트(Node.js), 백엔드(Tomcat, 젠킨스 서버는 3개 모두 도커 컨테이너 위에서 실행된다.
도커 설명은 자세히 안배웠으니 패스.