[TIL] 항해99 17일차

JISU·2021년 11월 17일
0

부트캠프

목록 보기
18/20

오늘 한 것


오늘 배운 것

AWS S3 배포

S3 버킷에 배포하기

S3 버킷에 배포한 후 사이트에서 주소창에 /이동할페이지 를 입력해서 이동하면 오류가 뜬다.

  1. 발생하는 이유
    일단 웹앱 안에서 동작하는 링크(혹은 버튼)을 눌러서 이동하는 것은 동작한다.
    왜냐면 react는 이 동작을 인지하고 있고, listen해서 route를 업데이트 해줄 수 있기 때문이다. 그런데, 로드되지 않은 스크립트(index.html, bundle.js)로 이동하게 되면, JS는 로드된 적이 없고 url에서의 request를 처리할 방법이 없는 것이다.

    react router 사용할 때 url /home /review 이런식으로 page를 가지고 있는데,
    문제는 S3에서 저 가상 url에서 refresh하게 되면, 404 혹은 403 에러가 발생하게 된다. 왜냐면 S3 버켓에 저기에 상응하는 파일이 없으니까 (/home /review 이건 컴포넌트로 이동하는 뭐 가상 url이지 진짜로 home.html 파일이 있어서 거기 페이지로 이동하는 것이 아니니까..?)

  2. 해결 방법
    정적 웹사이트 호스팅(Static website hosting) 설정엣 Routing Rules를 추가해주는 것이다!
    가상 url로 이동했을 때 404, 403 error가 발생하므로

    저기 안에 이러한 코드를 넣는 것이다.

<RoutingRules>
    <RoutingRule>
        <Condition>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <HostName>myhostname.com</HostName>
            <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
    <RoutingRule>
        <Condition>
            <HttpErrorCodeReturnedEquals>403</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <HostName>myhostname.com</HostName>
            <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
</RoutingRules>

이 코드는 S3에서 404 / 403 error 발생하면 url을 /home /review 앞에 #!를 붙여서 다시 쓰게 하는 것이다.

그러면 저 더러운 url을 그대로 쓸 수 있는가?
는 아님.
그래서 render 될 때 처리 한 번 더 해주어야 함.

if (app) {
    // 1. Set up the browser history with the updated location
    // (minus the # sign)
	const path = (/#!(\/.*)$/.exec(location.hash) || [])[1];
	if (path) {
		history.replace(path);
	}

    // 2. Render our app
	render(<App />, app);
}

path에 #! 있으면 빼주고 다시 url을 /home /review로 바꿔줌으로써 해결할 수 있다.

근데 난 왜 이거 안해줘도 되었던 거지?

Error Document에 index.html 넣어주는 것도 트릭키하게 해결할 수 있는 방법이라고 한다.
애초에 404 403 error가 발생했어도 index.html을 반환하게 하면 된다는 설명같음.

[출처] https://via.studio/journal/hosting-a-reactjs-app-with-routing-on-aws-s3
[출처] https://stackoverflow.com/questions/51218979/react-router-doesnt-work-in-aws-s3-bucket

패키지 매니저

npm

NPM은 Node Package Manager로 모바일로 치면 앱 스토어 같은 것이다.
Node.JS를 설치하면 자동으로 설치되는 것이다.

잠깐, Node.JS가 정확히 뭐야..

  • Node.JS란?

    	> 크롬 V8 자바스크립트 엔진으로 빌드된 런타임

    런타임(특정 언어로 만든 프로그램들을 실행할 수 있는 환경)

    	자바스크립트 언어로 서버를 구축할 때 쓰인다라는 것으로 이해하자.

    javascript는 일반적으로 브라우저에 내장되어 있기 때문에 브라우저 콘솔에 입력해도 잘 동작하는 것이다.
    이런 javascript는 브라우저에 종속된 언어인데, 이를 밖으로 꺼내서 사용하는 데에 Node.js가 필요한 것이다.
    => server(밖)에는 브라우저가 없으니 그냥 javascript를 사용할 수 없으니 이러한 런타임이 필요한 것

  • NPM이 무엇인지?
    그래서 Node.js 깔았더니 NPM(Node Package Manager)이 왔다 이 말이다.

풀 네임처럼 Node.JS에 필요한 패키지들을 관리한다.
필요하다면 npm을 이용해서 구축하려고하는 어플리케이션에 필요한 모듈을 찾아보고, 다운로드 할 수 있다는 것이다.
(내가 필요한 패키지들을 검색, 설치, 삭제, 업데이트 할 수 있는 것)

  • NPM의 특징
    1) 장점
    사실 NPM의 장점은 아니고, NPM이 제공되어 좋은 모듈을 다운받을 수 있다는 것이 좋은 것이다.
    처음부터 잘 짜여진 모듈(패키지 => 소프트웨어 / 어플리케이션 / 프로그램 등)을 다운 받도록 도와준다.
    -> react-app을 혼자서도 구축할 수 있겠지만 그 많은 hook들하고 기능하고 언제 다할까. 이미 다 되어서 페이지만 커스텀할 수 있는 모듈을 다운 받으면 그만인데.
    잘 짜여진 모듈을 다운 받는 것이므로 프로젝트의 성능도 좋아지고, 보안면에서도 아주 좋다고 한다.
    2) 단점
    하지만, 위의 장점은 언제까지나 잘 짜여진 모듈에 해당하는 것이다.
    모듈이 페이지와 맞지 않아 커스텀하거나 모듈에 에러가 있는 경우 그 모듈을 수정하기 쉽지 않다.
    또한, npm은 모듈 설치가 비교적 느리다.

이를 대체하기 위해 페이스북에서 yarn이라는 것을 도입했다. 밑에서 따로 NPM과 YARN을 비교해보도록 한다.

  • 사용 방법
    패키지들은 완성품도 있고, 부품도 있다.

[npmjs.com] 여기서 필요한 패키지들을 검색할 수 있다.

기본적으로 npm은 CLI(Command Line Interface)으로 git 처럼 git clone , git add와 같이 커맨드 창에서 명령어로 실행할 수 있다.

1) 패키지 다운

> npm install -g local-web-server

-g 글로벌 즉 전역에서 설치
아무것도 안쓰면 로컬에서 설치

> sudo npm install -g local-web-server

sudo 를 앞에 붙여주면 관리자 권한으로 실행해주는 명령어가 된다.

2) 실행
다운받은 패키지 실행방법을 찾아보고 실행하면 된다.
보통 ^c (ctrl + c) 종료

3) 탐색
커맨드 창에 npm 치면 사용할 수 있는 명령어들 나온다.

npm list
현재 폴더에 깔린 패키지 리스트 알려줌

npm list -g 하면 전역에 깔린 패키지 알려줌

npm list -g --depth-0 직접 설치한 패키지만 알려줌

4) 패키지 업데이트 / 삭제
업그레이드
npm update local-(패키지 이름) -g

삭제
npm uninstall -g (패키지 이름)

yarn

아까 전에 yarn이 더 빠르다고 했는데, 왜 어떻게 빠른 것일까?

  1. 병렬 설치
    패키지를 설치하면 작업을 수행하게 되는데, npm은 여러 패키지를 설치할 때 하나의 패키지가 완전히 설치가 끝나야 다른 패키지를 설치하기 시작한다(순차적으로 진행)
    하지만, yarn은 이러한 작업을 병렬로 설치하기 때문에 퍼포먼스와 속도가 증가하게 된다.

따라서 react를 설치했을 때 yarn으로 설치했을 때가 훨씬 빠른 것을 확인할 수 있다.

npm — 3.572 seconds
Yarn — 1.44 seconds

  1. 자동 lock 파일 생성
    npm과 yarn 모두 패키지에서 프로젝트의 종속성(dependency)의 버전 번호를 추적한다.
    json 파일의 종속성들을 설치할 때마다 종속성 버전이 버전 번호 앞에 ^시작되는 것들이 있다.
    즉, 다른 시스템에 모든 패키지를 설치하거나 설치할 명령을 수동으로 실행할 때마다 패키지 관리자가 릴리즈된 최신 버전을 찾는다. 최신 버전이 있으면 패키지 파일에 있는 버전이 아니라 최신 버전을 냅다 그냥 깔아버린다.

이를 방지하기 위해서는
1) 패키지 파일에 ^를 제거하는 방법과
2) 잠금파일을 생성해서 한번에 특정 버전만 설치하는 방법
이 있다.

종속성이 추가되면 yarn은 yarn.lock 파일을 자동으로 추가한다. npm은 npm shrinkwrap 명령어로 lock 파일을 생성했으나, 현재는 업데이트되면서 lock.json 파일을 제공하면서 추가적으로 명령어를 입력하지 않아도 되도록 업데이트되었다. 그러나, 속도는 yarn을 따라가지 못한다.

  1. 보안
    npm은 다른 패키지를 즉시 포함시킬 수 있는 코드를 자동으로 실행하므로 보안에 취약해진다. 반면, yarn은 yarn.lock 혹은 package.json 파일에 있는 파일만 설치한다.
    이런 면에서 yarn의 보안성이 더 좋다고 말하는 것이다.

[출처] https://javascript.plainenglish.io/npm-vs-yarn-choosing-the-right-package-manager-a5f04256a93f

profile
블로그 이전

0개의 댓글