프론트, 백 분리

최종윤·2023년 1월 20일

목록 보기

2/13

참고 : https://it-eldorado.tistory.com/85 React
프론트 엔드와 백 엔드 분리 시 동작 원리 (vs 풀 스택)

https://inpa.tistory.com/entry/JS-%F0%9F%93%9A-Ajax-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC
Ajax 기초 개념

https://velog.io/@dbekdms17/Spring%EC%97%90%EC%84%9C-ajax%EC%82%AC%EC%9A%A9
Spring에서 Ajax 사용

https://velog.io/@kimtaeeeny/%EC%9B%B9%EC%97%90%EC%84%9C%EC%9D%98-%ED%94%84%EB%A1%A0%ED%8A%B8-%EC%84%9C%EB%B2%84-%EB%B0%B1%EC%97%94%EB%93%9C-%EC%84%9C%EB%B2%84-%EA%B0%9C%EB%85%90-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-study6
프론트 서버와 백엔드 서버

https://velog.io/@me2designer/GitHub-%EB%82%B4-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%97%B0%EA%B2%B0whois.co.kr
github repository에 내 도메인 연결

프론트와 백엔드의 github repository를 분리하여 작업하게 됐다.
처음하는 팀 프로젝트라 어떻게 동작하는지 검색해보았다.

분리했을 때 차이점은?

JSP+ Spring 을 하나의 repository에서 보관할 때와,
React, Spring을 각각 다른 repository에서 관리할 때 차이점은?

하나의 repository에서 관리할 경우

하나의 repository에 관리할 때 Back의 Controller에서 String 반환 타입의 값으로 resource(html)의 파일 이름을 반환하면, resources경로에서 같은 이름을 갖는 html에 DB에서 가져온 데이터를 넣어서 완전한 HTML을 프론트로 전달하였다.

분리된 경우

근데 분리되면 backend의 프로젝트 폴더와 front의 프로젝트 폴더가 다르다.
String을 반환해도 resources에 HTML 파일이 없다.

분리된 경우에는 back에서 HTML을 client로 응답하는 것이 아닌 데이터만을 전달하고
Client에서 전달받은 데이터를 가지고 완전한 HTML을 만들어 화면을 보여줍니다.

back에서는 @ResponseBody로 데이터를 응답으로 전달하기만 하면 되는 것입니다.

번들링이란?

여러 파일로 나누어져있는 모듈(파일)을 의존성 관계를 파악하여 그룹화하는 작업입니다. 프론트에서 번들링도구로 성능이 좋은 Webpack을 주로 사용합니다.
각각의 모듈들은 그거 하나만으로 존재하는 독립적인 존재가 아닐겁니다. 적절히 의존성을 설정하여 모듈들간 의존성을 갖도록 합니다.
번들링은 모듈들간 연결하는 것 뿐아니라 이 두 가지 문제를 고려하여 그룹화하는 듯 합니다..

하나. 여러 개의 파일을 브라우저에서 로딩한다면 네트워크가 그만큼 소모되어 속도가 저하될 수 있습니다.
둘. 모듈 간의 변수 충돌 등의 위험성이 존재합니다.

프론트 엔드 서버란?

Webpack

Webpack 이라는 모듈 번들러가 HTML, CSS, JavaScript 파일들을 효율적인 방식으로 적절히 번들링하여 프론트엔드 서버의 다큐먼트 루트에 준비하고, 웹 서버가 그 파일들을 제공할 수 있도록 설정해야 합니다.

Babel

개발자가 React 라이브러리를 활용하여 클라이언트에게 제공할 JavaScript 파일들을 ES6 + JSX 문법으로 코딩하면, Babel 등의 컴파일러가 그것들을 모든 브라우저에서 호환이 가능한 문법(ES5)의 코드로 변환해준다.

그리고 실제 배포 시에는 번들링 한 파일들을 프론트 엔드 서버의 다큐먼트 루트에 미리 준비해두고 웹 서버가 그 파일들을 제공할 수 있도록 설정해야 한다.

프론트 엔드 서버는 사용자가 URI를 통해 브라우저의 사이트에 접속했을 때, HTML파일을 응답으로 전달합니다. (정적 리소스 전달)

전달받으면 클라이언트의 브라우저는 페이지에 (DOM에 새로고침 없이 데이터를 보여줌) 렌더링을 시작합니다. (React가 받은 DB데이터, 정적 리소스에 렌더링)
렌더링 :UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업을 의미한다.

데이터가 필요한 경우에는 백 엔드 서버에 요청을 보내서 데이터를 요청합니다.
(DB 데이터 전달)

이후, 변경되는 데이터를 화면에 리렌더링할 때, 페이지를 리로드 하지 않고, 사용자의 버튼 클릭과 같은 액션을 감지하여 API 서버에 요청을 보내, 해당 부분만 React를 활용하여 리렌더링을 해주게 됩니다.
(SPA)

ㅋㅋ

※ CORS 및 쿠키 문제

백 엔드 서버와 프론트 엔드 서버가 서로 다른 도메인을 가지는 경우, 다음과 같은 두 가지 문제점이 발생한다.
첫째, 기본적인 CORS 정책은 다른 오리진의 자원에 접근하는 것을 막는다는 문제이다. 따라서 백 엔드 서버에게 API 요청을 보내면 CORS 정책에 의해 요청이 거부당할 것이다. 이를 해결하려면 백 엔드 서버 쪽에서 CORS를 허용하기 위한 별도의 설정을 해줘야 한다.

다음으로, 다른 오리진에 대한 요청 시에는 쿠키를 전송 혹은 수신할 수 없다는 문제이다. 즉 백 엔드 서버에게 API 요청을 보내더라도 쿠키가 설정되지 않기 때문에 로그인 등의 기능을 구현하는 것이 어려워진다. 이를 해결하려면 백 엔드 서버에게 API 요청을 보낼 때 JavaScript 단에서 특정 설정(XMLHttpRequest.withCredentials 옵션을 true로 설정하거나, fetch API라면 credentials 옵션을 include로 설정)을 해줘야 하며, 백 엔드 서버 쪽에도 응답의 헤더에서 Access-Control-Allow-Credentials 옵션을 true로 설정해줘야 한다. (참고)

한편 이것과 별개로 쿠키의 SameSite 옵션에도 주의를 기울여야 하는데, 기본적으로 Lax로 설정이 되기 때문에 GET 요청과 같은 안전한 요청이 아닌 이상 동일한 도메인일 때만 쿠키가 전송될 수 있다. 여기서 말하는 동일한 도메인이란 1차 도메인과 2차 도메인까지만을 말한다. 즉, a.naver.com과 b.naver.com은 동일한 도메인으로 취급된다. (참고)

Origin: URI에서 프로토콜:도메인 이름:포트번호 까지를 origin이라한다
서버의 Origin(출처)가 다르면 요청자체가 거절하도록 만들어져있구나,
으흠, 같은 도메인일때만 쿠키가 전송되니까, 다른 오리진으로 요청시 쿠키를 전송 수신할 수 없는데, 로그인할 때는 쿠키가 있어야하니까, 로그인 구현하려면 다른 도메인이어도 쿠키를 보낼 수 있도록 해야겠네, 설정방법이 위와 같은 거구나,
근데 응답의 헤더 옵션을 어떻게 설정할까?

github repository 도메인 연결

도메인을 구매한 후
GitHub 레파지토리(Repository)에 도메인 연결
GitHub 접속 후 도메인 연결하고자하는 레파지토리를 선택 후 아래 그림 처럼 Settings > Pasges 메뉴를 선택하여 Custom domain 입력란에 내 도메인 주소와 CName 레코드에 등록한 서브도메인을 포함한 전체 주소를 입력하고 Save를 실행합니다.
(예: www.도메인주소, test.도메인주소, blog.도메인주소 처럼 서브도메인을 포함한 전체 도메인주소)

Save를 실행하고 3~6초 정도 시간이 지나면 "Your site is published at 내 도메인 주소명" 메세지가 표시되며 해당 주소로 접속하면 정상적으로 연결되는 것을 확인 할 수 있습니다.