다른 포스팅을 하기에 앞서서 'ASP.NET Core'에서 프론트 엔드 개발(Front-end)을 어떻게 하는지 설명하고 가고자 합니다.
1. 기존 방식
기존에는 자바스크립트와 html로 날 코딩을 했습니다.
'ASP.NET Core'에서 디버깅하면 로컬 웹서버가 자동으로 동작하니
출력 폴더(기본값 'wwwroot')에서 직접 파일을 수정하고 새로고침하면서 작업을 했습니다.
2. 프론트 엔드도 빌드해야한다.
프론트엔드가 날로 복잡해지면서 빌드의 필요성이 생겼고,
거기에 부흥하여 각종 빌드환경이 생겨났습니다.
그래서 빠른 테스트를 위해서 프론트 엔드도 자신만의 로컬서버가 필요해졌습니다.
이러면서 생긴 문제는 프론트 엔드 빌드환경과 기존 개발환경을 어떻게 통합하느냐입니다.
3. 'ASP.NET Core' 개발환경과 통합
찾아보면 방법이야 더 있겠지만 제가 생각하기엔 크게 3가지가 있는 거 같습니다.
3-1. 프로젝트를 각각 개발
심플하게 백엔드용 프로젝트와 프론트 엔드용 프로젝트를 따로 만드는 겁니다.
(참고 : MS Docs - 자습서: Visual Studio에서 React를 사용하여 ASP.NET Core 앱 만들기 )
이렇게 되면 통합이고 자시고 그냥 각각 돌리는 것이라 아무 문제 없습니다.
개발부서가 완전히 분리돼서 돌아가고 API문서로만 소통한다면 이것보다 좋은 방법은 없을 겁니다.
단점은
- 한 개의 프로젝트를 2개로 나눠야 한다는 심리적 부담감
- API용 서버를 실행시키고 수동으로 프론트엔드 서버도 실행시켜야 합니다.
(물론 세팅을 해서 해결할 수 있습니다.)
3-2. 출력 폴더만 공유
한 개에 프로젝트에 'ASP.NET Core'와 프론트 엔드용 환경을 둘 다 넣어두고
프론트 엔드 빌드 출력물을 'ASP.NET Core'의 출력 폴더로 복사하도록 구성하는 것입니다.
지금은 'IIS Expres'나 프로필 서버도 핫리로드를 지원하므로
이 방법으로 구성하면 프론트엔드 빌드 때마다 자동으로 화면갱신도됩니다.
'ASP.NET Core' 서버만 올리면 되니 테스트하기도 비교적 편하다는 장점이 있습니다.
단점은
- 구성이 복잡하다.
경로 설정할 때 지옥을 경험할 수 있습니다 ㅎㅎㅎ
빌드 구성파일을 단계별 추적이 안 되니 생각대로 동작 안 하면 한땀한땀 읽은 파일과 출력 파일 위치 봐가면서 수정해야 합니다.
거기다 디버그용(development) 빌드와 릴리즈용(production) 폴더도 구분해야 하므로 첫 구성 때 고생을 꽤 합니다.
디버깅 설정까지 한다면.......
그나마 이런 설정은 한번 확정되면 건딜일이 없다는 게 다행이죠.
3-3. 프록시 혹은 전달
'ASP.NET Core'서버에서 프론트 엔드 서버로 프록시를 해주도록 구성하는 것입니다.
'ASP.NET Core'서버가 올라오면 자동으로 프론트 엔드 서버를 올린 후 프론트 엔드 서버로 이동합니다.
(Microsoft.AspNetCore.SpaProxy 이용)
'ASP.NET Core'의 프론트 엔드 템플릿들이 이런 식으로 구성되어 있습니다.
별도의 구성없이 몇 가지 세팅만 하면 됩니다.
템플릿으로 생성하면 디버깅까지 논스톱으로 할 수 있습니다.
아니면 프론트엔드 서버는 계속 띄워두고 'ASP.NET Core'서버가 올라오면 프론트 엔드 서버의 페이지로 이동하도록 구성해도 됩니다.
(이러면 3-1. 방법과 같아진다고 볼 수 있습니다.)
단점은
- 인증 이슈
토큰이나 https 이슈가 생길 가능성이 있습니다.
물론 검색하면 해결법은 다 나옵니다 ㅎㅎㅎㅎ
"React.js를 사용한 ASP.NET Core" 템플릿
이 템플릿을 사용하면 리엑트와 ASP.NET 설정이 한 번에 되고,
디버깅 설정까지 한 번에 연결해줍니다.
(중단점 잘 잡힘)
덩치가 크고 너무 느리다는 단점은 있지만 압도적인 편리함이 있으니.....
그리고 생각보다 자료가 없어서 내부 구성이 어떻게 돼 있는지 찾지를 못했습니다.
코드가 복잡해서 하나하나 분석하기도 힘들어 보이는데 말이죠...
마무리
이런 문제는 정답이 없습니다.
제가 제시한 방법 말고도 더 있을 수 있습니다.
자신에게 맞는 방식을 찾아야 하겠죠?
