async/await

Promise 체인을 구축하지 않고도, Promise를 직관적으로 사용할 수 있는 문법이다. 많은 프로그래밍 언어에 있는 try...catch 문으로 에러를 직관적으로 처리한다. async function을 만들고, Promise를 기다려야 하는 표현 앞에 await을 붙인다.

async/await

async function fetchUsers() {
	try{
    	const users = await request('/users')
        console.log("users fetched.")
        return users
    } catch (e) {
    	console.log("error : ", e)
    }
}

Promise

function fetchUsers() {
	return request('/users)
    	.then(users => console.log("users fetched.))
        .catch(e => console.error("error : ", e))
}

async/await - 여러 개의 await

여러 개의 await을 순서대로 나열하여, then chain을 구현할 수 있다. try...catch 문을 자유롭게 활용하여 에러 처리를 적용할 수 있다.

async function fetchUserWithAddress(id) {
	try{
    	const uer = await request(`/user/${user.id}`)
        const address = await request(`/user/${user.id}/address`)
        return {...user,address}
    } catch (e){
    	console.log("error : ", e)
    }
}

async/await - Promise 와의 조합

Promise.all은 특정 비동기 작업이 상대적으로 빠르게 끝나도 느린 처리를 끝까지 기다려야만 한다. 이와 달리, async/await을 활용할 경우 parallelism을 구현할 수 있다. 즉, 끝난 대로 먼저 처리될 수 있다.

async function fetchUserWithAddress(id) {
	return await Promise.all([
    	(async () => await request(`/user/${id}`))(),
        (async () => await request(`/user/${id}/address))(),
    ]);
}

fetchUserWithAddress('1234')
	.then(([user, address]) => ({ ...user, address }))
    .catch(e => console.log("Error : ", e))

POSTMAN

서버와의 통신을 위해 API를 활용하는 경우, React 앱으로만 요청하여 API가 잘 동작하는지 알아보는 건 비효율적이다. 수 많은 API의 endpoint와 실행 조건 등을 관리하는 것도 힘들다. POSTMAN은 API를 테스트하기 위한 개발 도구이다.

Auth, header, payload, query 등 API 요청에 필요한 데이터를 쉽게 세팅한다. 다른 개발자가 쉽게 셋업해 테스트할 수 있도록 API 정보를 공유할 수 있다. Request를 모아 Collection으로 만들어, API를 종류별로 관리한다. 환경 변수를 정의하여, 환경별로 테스트 가능하다.

Open API

RESTful API를 하나의 문서로 정의하기 위한 문서 표준이다. OpenAPI Specification(OAS)으로 정의된다. Swagger 등의 툴로, Open API로 작성된 문서를 파싱해 테스팅 도구로 만들 수 있다. 프론트엔드 개발자, 백엔드 개발자의 협업 시 주요한 도구로 사용된다.

API의 method, endpoint를 정의. endpoint마다 인증 방식, content type 등 정의. body data, query string, path variable 등 정의. 요청, 응답 데이터 형식과 타입 정의 - data model 활용(schema)

CORS(Cross-Origin Resource Sharing)

브라우저는 모든 요청 시 Origin 헤더를 포함한다. 서버는 Origin 헤더를 보고, 해당 요청이 원하는 도메인에서부터 출발한 것인지를 판단한다. 다른 Origin에서 온 요청은 서버에서 기본적으로 거부한다. 그러나 보통 서버의 endpoint와 홈페이지 domain은 다른 경우가 많다. 따라서 서버에서는 홈페이지 domain을 허용하여, 다른 domain이라 하더라도 요청을 보낼 수 있게 한다.
서버에서는 Access-Control-Allow-Origin 외에 Access-Control-*을 포함하는 헤더에 CORS 관련 정보를 클라이언트로 보낸다.
웹사이트에 악성 script가 로드되어, 수상한 요청을 하는 것을 막기 위함이다. 반대로, 익명 유저로부터의 DDos공격 등을 막기 위함이다. 서버에 직접 CORS 설정을 할 수 없다면, Proxy 서버 등을 만들어 해결한다.