week02 - 비동기 처리, HTTP, REST API, Express

[hyejungg]

🔥 알게된 점

1. 비동기처리
2. HTTP
3. REST API
4. Express

📚 배운 점

동기 / 비동기, 그리고 비동기 처리를 사용하는 이유

1. 동기

• 어떤 작업이 끝나기 전까지 다음 작업을 실행하지 않음
• 요청에 대한 응답이 완료될 때까지 기다림
• 백그라운드 작업 완료 여부 계속 확인

2. 비동기

• 작업의 완료 유무와 상관없이 동시에 다음 작업을 수행 가능
• 요청만 보내고 다시 프로그램 처리
• 백그라운드가 완료 알림을 주면 미리 지정한 이벤트 처리

Node는 대부분의 메서드를 비동기로 처리

Javascript는 기본적으로 싱글 스레드 언어이기 때문에 한 번에 한 작업을 처리하는 방식으로 동작함
비동기 처리를 스레드로 해결하지 않고, Event 방식으로 해결

비동기 처리가 필요한 이유는 동기 처리 시 메인스레드가 노는 시간이 발생함 === 비효율적

//*setitemout(콜백함수, 시간) : 시간 지난 다음에 콜백함수 실행
setTimeout(() => {
    console.log('Set Time out');
}, 2000); //1 seconds

console.log('끝');

/**************** output
 * 끝
 * Set Time out
 */

비동기 처리 방식

1. Callback Function

• 어떤 이벤트 발생 시, 특정 시점에 도달했을 때 시스템에서 호출하는 함수. 다른 함수의 인자로 사용
• 함수1의 작업이 끝나면 함수2의 작업을 하도록

콜백함수의 문제점

• 콜백지옥에 빠질 수 있음.
  • 비동기 처리를 위해서 중첩되어 콜백함수를 호출하게 됨
• 가독성도 떨어지고, 코드 이해가 어려움

2. Promise

• 콜백지옥을 극복하기 위해 ES2015부터 Node, JS API 들이 콜백 대신 Promise 형태로 재구성됨

Promise의 3가지 상태

1. Pending(대기) : 비동기 처리가 완료되지 않은 상태. Promise  생성 시점
2. Fullfiled(이행) : 비동기 처리가 완료되어 Promise 결과 반환 / resolve 호출
3. Rejected(실패) : 실패 또는 오류 / reject 호출

2.의 상태가 되면 then()으로 전달 가능
3.의 상태가 되면 catch()로 전달 가능

Promise Chaining

• 여러개의 프로미스를 연결하여 사용
• <Promise>.then() : 비동기 작업 완료 시 결과에 따라 함수 호출
• <Promise>.catch() : 체에닝 연결 상태에서 중간에 에러가 발생 시 호출

//order(), cook(), serving(), eat() 은 모두 Promise<T>를 반환하는 함수여야 함
order()
    .then(progress => cook(progress)) //order에서 받아온 값을 cook으로 넘겨
    .then(progress => serving(progress)) //cook에서 받아온 값을 serving으로 넘겨
    .then(progress => eat(progress)) //serving으로 받아온 값을 eat으로 넘겨
    .then(progress => console.log(progress)) //promise 체이닝이 끝나 콘솔에 출력
    .catch(error => console.log(error)); //? promise가 여러개 있어서 reject가 발생해도 단일 catch로 가능

3. Async/Await

• ES2017부터 제공되는 혁신적인 기능.
• Promise가 어느정도 콜백 지옥을 해결했지만, 여전히 코드가 복잡하고 어려움.
• 비동기 처리 방식이지만, 동기 코드와 유사하고 이해가 쉬움

(1) async : 암묵적으로 Promise를 반환

// 함수 표현식
const asyncFunction1 = async () => {

}
// 함수 선언식
async function asyncFunction2() {

}

(2) await : Promise를 기다림(resolve,reject). async 정의된 내부에서만 사용 가능

const asnycMain = async () => {
    let result = await asyncFunc1('server part');
    console.log(result);
    result = await asyncFunc2('김헤정');
    console.log(result);
}

HTTP (HyperText Transfer Protocol)

하이퍼텍스트 문서를 주고 받을 수 있는 프로토콜 (규칙)

1. Stateless Protocol : 무상태 프로토콜

• 모든 요청이 상호 독립적으로 이루어짐
• 서버가 request, response 간에 어떠한 데이터도 보존하지 않음
• 중간에 요청이 다른 서버로 들어가도 문제 없음
  • 소비자가 구매처 서버에 구매 요청을 하고 결제는 카드서 서버에서 결제 요청이 진행됨
  • 구매 요청과 결제 요청은 상호 독립적으로 이루어지므로 중간에 요청이 다른서버로 들어가도 문제 없음

2. HTTP Request
   (1) request start line : method, uri
   (2) request header : https header (부가정보들)

   • 어떤 형식으로 데이터가 전달되는지
   • 서버 정보
   • 호스트 정보
     등...
     (3) empty line : 빈 한줄
     (4) request body : 클라이언트가 서버에게 전달하는 요청 데이터 값 (json, MXL, Multi Form 등 데이터)

3. HTTP Method
   (1) GET / 조회 / query parameter, path parameter
   (2) POST / 생성 / request body
   (3) PUT / 수정 / request body
   (4) PATCH / 일부 수정 / request body
   (5) DELETE / 삭제

4. HTTP Response
   (1) response status : 요청에 대한 상태코드
   (2) response header : http header (부가 정보들)

   • 어떤 형식으로 데이터가 전달되는지
   • 서버 정보
   • 호스트 정보
     등...
     (3) epmty line : 빈 한줄
     (4) response body : 서버에서 가공한 정보를 클라이언트에게 전달할 데이터 값(json, MXL, Multi Form 등 데이터)

5. HTTP Status
   (1) 2XX : 성공 상태
   (2) 3XX : 리다이렉션
   (3) 4XX : 요청 오류
   (4) 5XX : 서버 내부 오류

• 더 많은 HTTP Status

REST API

• 리소스 지향 아키텍처인 REST 아키텍처를 준수하여 API를 작성하는 것

REST (REpresentational State Transfer)
: 서버의 자원을 정의하고, 자원에 대한 주소를 지정하는 방법
리소스 지향 아키텍처이므로 모든 것을 가급적 리소스, 명사로 표현
즉, REST 아키텍처를 준수하는 API

API (Application Programming Interface)
: 서버 어플리케이션의 기능을 사용하기 위한 방법
구현 방식을 몰라도 서비스가 서로 통신 가능

• URI는 정보의 자원을 표현
• 자원에 대한 행위는 HTTP Method로 표현

1. URI vs URL
   (1) URI(Uniform Resource Identifier)

• 통합 자원 식별자 (자원을 나타내는 주소)
• 자원을 나타내는 유일한 주소

(2) URL(Uniform Resource Locator)

• 통합 자원 지시자
• 특정 서버의 한 리소스에 대한 구체적인 위치 서술

URL < URI

2. REST API 기준
   (1) 클라이언트,서버 및 리소스로 구성. 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
   (2) stateless

   • 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
     (3) 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
     (4) 서버(보안, 로드 밸런싱 등을 담당)의 각 유형의 정보를 클라이언트는 볼 수 없는 계층화된 시스템
     (5) 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스

3. REST API 중심 규칙

- [내가 좋아하는 rest api 서술된 nhn 기술 문서](https://meetup.toast.com/posts/92)

Yarn

• npm에 보안을 추가하여 나온 패키지 매니저
• npm install yarn -g
• npm과 yarn은 같이 사용하면 안됨. (충돌 발생함. 주의하기)
• yarn --init : package.json 생성

참고문서

• rest api

[hyejungg]

Express 환경 설정

1. 작업 디렉터리 생성
2. yarn --init하여 package.json 생성
3. yarn add express, yarn add -D @types/node @types/express, yarn add -D nodemon 설치
4. tsc --init하여 tsconfig.json 생성. (typescript를 javascript로 컴파일하는 옵션 설정)

[hyejungg]

//tsconfig.json

{
  "compilerOptions": {
    "target": "es6", // 어떤 버전으로 컴파일
    "allowSyntheticDefaultImports": true, // default export가 없는 모듈에서 default imports를 허용
    "experimentalDecorators": true, // decorator 실험적 허용
    "emitDecoratorMetadata": true, // 데코레이터가 있는 선언에 대해 특정 타입의 메타 데이터를 내보내는 실험적인 지원
    "skipLibCheck": true, // 정의 파일 타입 체크 여부
    "moduleResolution": "node", // commonJS -> node 에서 동작
    "module": "commonjs", // import 문법
    "strict": true, // 타입 검사 엄격하게 
    "pretty": true, // error 메시지 예쁘게
    "sourceMap": true, // 소스맵 파일 생성 -> .ts가 .js 파일로 트랜스 시 .js.map 생성
    "outDir": "./dist", // 트랜스 파일 (.js) 저장 경로
    "allowJs": true, // js 파일 ts에서 import 허용
    "esModuleInterop": true, // ES6 모듈 사양을 준수하여 CommonJS 모듈을 가져올 수 있게 허용
    "typeRoots": [
      "./src/types/express.d.ts", // 타입(*.d.ts)파일을 가져올 디렉토리 설정
      "./node_modules/@types" // 설정 안할시 기본적으로 ./node_modules/@types
    ]
  },
  "include": [
    "./src/**/*" // build 시 포함
  ],
  "exclude": [
    "node_modules", // build 시 제외
    "tests"
  ]
}

[hyejungg]

//nodemon.json

• watch : 변경 감지 경로 -> nodemon 코드 변경 감지하여 서버를 자동으로 재시작
• ext : 변경 감지 확장자 -> js, ts, json 파일 변경 시 재시작
• ignore : 변경 감지 무시 (spec.ts는 테스트 코드)
• exec : nodemon을 실행하는 명령

{
    "watch": [ 
        "src",
        ".env"
    ], 
    "ext": "js,ts,json",
    "ignore": [
        "src/**/*.spec.ts"  
    ],
    "exec": "ts-node  --transpile-only ./src/index.ts"
}