프로젝트를 배포하는 방법
- 기본적으로 History API 기반의 SPA 를 배포하려면 해당 서비스에서 404 error 를 처리할 수 있는 옵션이 필요함. (hash bang 이나 url 처리가 필요 없는 단일 페이지의 경우에는 필요가 없음)
서버에서 직접 호스팅
- 여러 클라우드 업체에서 제공하는 서버에서 직접 호스팅 하는 방법 (EC2, Google Compute Engine, Azure, cafe24, iwin, Oracle, ...)
EC2
- cloud server 에서 git 리포지토리를
clone한 후,npx serve -s로 가상서버 상에서 run ... 서버의 IP 로 접속할 수 있다. - 복잡하고 난이도가 있는 편
aws s3 + Cloudfront 이용하기
- s3 는 일종의 파일만을 저장하는 서비스라고 할 수 있음 (html, css, js, image, video, ...)
프론트엔드의 정적인 요소를 s3에 업로드 하는 것만으로도 다른 사람들이 접근하여 사용할 수 있다.
실제 서비스에서는 이렇게 간단하게 쓰이지는 않음 (특정한 도메인에 연결하는 방식이 아니기 때문)
-cloudfront 를 통해 실제 접속을 받는 역할을 한다.
cloudfront 로 요청이 들어오면 s3에 요청하여 꺼내서 사용하는 방법
404 페이지 error 를 해결할 수 있다.
자체적인 캐시가 존재하여 유지하기 때문에 요청 속도가 상당히 빠름
404 error 발생 시, 바로 index.html 로 돌릴 수 있음
Github pages
- 공짜, 상징적인 url
- 리포지토리를
clone한 후npm install -y gh-pages,npm gh-pahes -d projetct명령어를 통해 리포지토리의 모든 내용물을 올림 - index.html 을 404.html 의 copy 본으로 두는 방식으로 404 error 를 처리함
- 도메인을 사서 포트폴리오 용으로 만들어 두면 좋을 것 (.dev 등...)
Firebase
- 다양한 API, 데이터베이스 등의 툴을 제공함
- 일정한 트래픽을 넘어가지 않는 선에서 개인 사용자는 무료
학습이나, 작은 규묘의 프로젝트를 다룰 때 유용함 - realtime DB 를 통해 별도의 API 없이 서버 기능을 이용할 수 있다.
- 404 error 시, 모든 경로의 요청을 index.html 로 돌려 에러를 처리함.
Netlify
- aws 혹은 firebase 보다 훨씬 배포가 간단하고 쉬운 장점이 있다.
- github 리포지토리와 직접 연동을 하는 방식
- 별도의 브랜치를 따로 배포할 수 있는 장점이 있음
- 브랜치의 변경을 자동으로 감지하여 자동으로 최신화를 진행함
- netlify 서버에 한국이 없어, 느린 속도의 단점을 가진다.
Vercel
- Netlify 와 유사함
- 한국 서버가 존재하여 netlify 보다 빠른 속도
회고
배포와 관련하여 간단하게 nuxt 와 netlify를 사용해 본 적이 있다.
배포 플랫폼을 다양하게 경험해보고, 도메인도 구매하여 사용해도 좋을 것 같다.
적어도 위의 플랫폼들정도는 한번씩은 모두 경험해보며 사용법을 익혀보도록 해야겠다.
프론트엔드