220627 프론트엔드 부트캠프 48일차 : 배포를 해보자!(1), 테스트 코드(jest), 리액트 네이티브

 

배포는 삼단계로 진행될 거예요!

 

SSR, SSG

 

이번주 커리큘럼...벌써 마지막이야

 

1. 배포를 위한 숲을 그려보자! -> Cloud-Provider

2. 배포하면 끝인줄 알았는데...-ㅅ- 테스트는 또 뭐야? -> Jest / Cypress / TDD 

 

  Cloud-Provider

 

 서버를 계속 켜놓으려면 24시간 컴퓨터를 켜놔야하고, 다른 사람도 내 컴퓨터에 접속할 수 있게끔 네트워크 설정도 조금씩 바꿔야 한다. 반드시 서버실의 서버컴퓨터로 할 필요는 없다. 하지만 접속자가 많아지면 노트북 같은 걸로는 힘들다... (처리를 하는 cpu와 기록해놓는 메모리,ram이 좋아야 한다.)

 

 Front를 여러대, 각각의 소스코드로 각각 yarn dev해서 한 대가 안돼도 다른 애가 켜져있어서 그쪽으로 접속이 가능하게 한다. 

 

 로드 밸런서(부하 분산기) - 여러대의 Front 중 접속량이 적은 컴퓨터로 요청을 전달해준다. 

 

round-robin

한 번씩 접속을 번갈아서 해주는 것

least connection

active session이 적은 쪽으로 라우팅

 

요즘은 시대가 바껴서 이런 네트워크 장비를 무수히 많이 가지고 있는 회사들이 있어(ex. 아마존, 구글, 마이크로소프트) 우리 컴퓨터 빌려다가 써! AWS, GCP, Azure

 

컴퓨터를 빌리고 그 컴퓨터에 접속할 수 있는 권한을 얻는 것

 

네트워크 서비스 - 부하 분산(로드 밸런서)

 

개발자도 마우스 몇 번 클릭해서 배포할 수 있게 되다보니까, 개발과 운영이 합쳐졌다. !

Development + Operations ⇒ DevOps (데브옵스) 데브옵스한다. 클라우드한다.

 

AWS, GCP, Azure - Cloud Provider 라고 한다.

 

브라우저에서 aaa.com치면 DNS에 들어가게 됨. aaa.com은 10.123.456.789 야~ 라고 매핑 시켜놓음

 

 꼭 로드 밸런서 통해서가 아니라 다이렉트로 컴퓨터로 접속할 수도 있겠지. 하지만 부하 분산을 위해서 로드 밸런서 통해서만 접속한다. 주소를 외우고 다닐 수 없기 때문에 DNS에 등록을 해놓는다.

 

 그러면 누구는 바로 들어오고 누구는 로드 밸런서를 통해 들어오고,… 바로 들어오는 애들 막을 수 없나요?

그래서 일반적으로 컴퓨터들 앞에 방화벽으로 막혀있다. 다른 컴퓨터가 직접 못들어오게끔 막아주는 역할. (기본세팅)

 

naver.com 들어가면 사실은 223.130.195.95 로 들어가지는 것!

 

  SSR, SSG

1. yarn build로 html, css, js 미리 만들어놓아. 그리고 그걸 Cloud-Storage에 업로드! 그리고 Cloud-front에 등록을 시켜놔. 그 후 주소를 바꿔야지 도메인 로드밸런서로 연결하는게 아니라 클라우드 프론트로 연결되게끔 해야지. 그리고 거기서 다운로드 받아와서 보여줘.
2. 로드 밸런서를 통해서 부하를 분산시키고 안에는 yarn dev 24시간 켜져있어야 하는 방식

( 단점 : 컴퓨터가 켜져있어야만 접속이 가능하다. 컴퓨터 모니터링도 해야한다. cpu, 메모리… 컴퓨터 종료되면 안되니까 )

 

 

1번 - SSG 배포(Static Site Generation) 컴퓨터 모니터링 할 필요가 없다. 정전 걱정도 없다. 무한으로 트래픽 받을 수 있다. 무한 트래픽이 가능하다.

간단하게 만들 때 1번 방식으로 한다. 정적 파일(html, css, js) 미리 만들어놓고 업로드 하는 방식

넷틀리파이가 이런건가봥

 

2번 - 왜 굳이 배포 2번이 필요한거야? 1번은 변함이 없는, 정적인 파일만 배포가 가능해. 동적으로 변하는 파일들은 이게 안돼! dynamic routing(주소가 매번 동적으로 바뀌어) 미리 html 파일을 만들어놓을 방법이 없어.

openGraph 동적으로 만들어지는 부분들이 있었어. 이런 부분들이 들어가게 되면, 그땐 미리 만들어놓을 수 있는 방법이 없다. 엄지 보고 싶다. 까치도…

[boardId] 이렇게 생겨나는 애들… 정적 제너레이션 할 수가 없어.

 

우리는 우리가 만든 프로젝트를 지금까지 yarn dev를 통해 ‘내 컴퓨터’안에서만 구동시켰죠? 하지만 외부 다른 컴퓨터에서도 접근이 가능하고 싶다면 외부 컴퓨터를 빌려 배포를 진행해야 했습니다! 물론 우리가 가지고 있는 컴퓨터로도 배포가 가능하죠! 하지만 해당 컴퓨터를 24시간 구동시켜야하기 때문에 외부 컴퓨터를 빌려 배포를 진행하는 것이 효율적이였습니다!(경제적 측면) 예전에는 배포를 어떻게 했는지 먼저 알아봤었죠! 서버컴퓨터와 DB컴퓨터를 직접 사용하여 진행했습니다! 하지만 이 방식에는 문제가 있었죠! 사용량이 증가하게 될 경우 서버 컴퓨터에 무리가 생겨 부하를 분산 시켜주었어야 했습니다! 그렇기에 서버 컴퓨터를 하나 더 구매하여 분산시켜 주었습니다! LB(LoadBalancer)를 사용해 각각의 컴퓨터에 사용량을 분산시켜 해결한다고 했던것 기억나시죠!? 또한, 실물 컴퓨터를 구매하던것을 이제는 CloudProvider 서비스를 사용하여 컴퓨터를 대여하게 되었죠!? 대표적으로 AWS(AmazonWebServices),GCP(GoogleCloudPaltform),Azure 등이 있었습니다! 이렇게 클라우드 서비스를 사용하여 컴퓨터를 대여하여 해당 컴퓨터 안에서 git clone, yarn dev 등 명령어를 그대로 사용해 배포를 진행할 수 있었습니다! gcp의 compute EngineVM인스턴스를 통해 가상 컴퓨터를 빌릴 수 있었죠!? 이 안에서 인스턴스 만들기를 통해 빌리려는 컴퓨터의 사양과 지역을 고를 수 있었고, 부팅 디스크에서 컴퓨터의 운영체제를 선택 할 수 있었습니다! 가상 컴퓨터를 대여한 후 SSH를 통해 해당 컴퓨터에 접속할 수 있었습니다! 우리는 이 컴퓨터를 24시간 꺼지지 않도록 설정하여 우리가 배포한 사이트가 항상 접근이 가능하도록 해주는 것 이였습니다! 우리가 빌려놓은 컴퓨터의 ip로 접속하는 방식은 번거로웠죠! 따라서 우리가 구매하는 도메인을 연결시켜주어 도메인 주소를 통해 해당 사이트에 접속하게 될 경우 해당 ip로 변경해 접속할 수 있도록 해주었어야 했습니다! 네트워크 서비스 - Cloud DNS(Domain Name System) 에서 설정해 주었죠!? 배포를 하게 될 경우 크게 두 가지 영역에 배포를 진행한다 했습니다! Storage와 Frontend-Server였습니다! html,css,js 등을 Storage에 저장시킨 후 Browser에서 Storage에 접근하여 html,css,js를 다운로드 받는 방식을 위한 Storage배포와 SSR이 필요한 페이지에 접근할 경우, Browser에서 Frontend-server에 접근한 후 Backend-server -> DataBase에 접근하기 위한 Frontend-Server배포였습니다! 즉, 주소(DNS)에 따라 어디로 접근하여 필요한 데이터를 받아올지가 나뉘게 되는 것인데, 이런 방식을 구분시켜주는 도구! 로드밸런서(LB)가 Browser에서 Storage 혹은 Frontend-server에 접근하기 전, 어디로 접근할지 판단하여 나누어 준다고 했습니다! 그렇기에 Storage/Frontend-server 앞에 붙여준다고 했습니다! 다시말해, 접속하는 도메인 주소에 따라 입력된 값을 LB가 판단하여 Storage로 연결시킬지, Frontend-server로 연결시킬지 구분해준다고 했습니다! 기억나시죠!? 하지만 이 Frontend-Server에 아무나 접근하면 안되겠죠! 따라서 우리는 방화벽을 설정하고, 우리가 지정한 특정 접근으로만 방화벽이 열리게 설정해주어야 했습니다!

 

 

  테스트 코드 (Jest)

자료가 너무 귀엽다. 

나는 정들어버릴것이다...

 

script에 추가 후 yarn test 하면 실행됨

nextjs jest < 쳐서 여기서 알려주는 사용방법 따라하면 훨씬 쉽다.

Jest and React Testing Library

Testing | Next.js

 

yarn add --dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom

 

testing-library/react 의 버전을 12.1.2로 낮추고 노드모듈즈를 지우고 다시 yarn install 한다.

 

그리고 jest.config.js 만들고 복사 붙여넣기(독스에 있음)

 

// jest.config.js
const nextJest = require('next/jest')

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './',
})

// Add any custom config to be passed to Jest
const customJestConfig = {
  // Add more setup options before each test is run
  // setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  // if using TypeScript with a baseUrl set to the root directory then you need the below for alias' to work
  moduleDirectories: ['node_modules', '<rootDir>/'],
  testEnvironment: 'jest-environment-jsdom',
}

// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
module.exports = createJestConfig(customJestConfig)

index.spec.ts

index.test.ts

 

spec이나 test로 생성하면 된다. 

 

eslintrc.js에서 jest/globals 추가

plugins: ["react", "@typescript-eslint", "jest/globals"],

 

package.json에 추가

"test": "jest --watch"

 

 

e2e(end to end) - Cypress 

 

yarn add --dev cypress

 

  리액트 네이티브(React-Native)

 네이티브는... 설치 과정이 어렵기에 Expo CLI 를 설치했다.

Expo는 리액트 네이티브를 기반으로 구축되어 Android studio나 Xcode를 설치하지 않고도 프로젝트를 실행할 수 있어서 편하지만, 제공되어진 API만 사용이 가능하다. 그리고 Object-C, Swift, Java, Kotlin으로 작성된 Native Module은 추가할 수가 없다. Expo SDK 솔루션으로 빌드되어 빌드하는 데 시간이 오래 걸린다. 

 

 리액트 네이티브는 설정은 오래걸리지만 모든 라이브러리를 사용할 수 있고 자유도가 높다. 본격적으로 앱 개발을 하려면 React-Native 를 쓰면 된다!. 

 

 

 리액트 네이티브 안의 태그들은 다 만들어진 컴포넌트 같은 것,,, import해서 써야하고 속성 안 먹히는 것들이 있을 수 있다.텍스트는 꼭 <Text>태그 안에 써야한다. 

 

 

yarn add @emotion/react @emotion/native