매개변수/GraphQL

매개변수

여태까지 우리는 다양한 매개변수를 사용하고 있었고 자주 사용하던 props, el, prev도 모두 함수의 매개변수이다. 그리고 이러한 매개변수는 아무렇게나 이름을 지어도 상관없지만 관례상 props, el, prev로 사용하고 있으며 이를 바꿀 시 협업 시 문제가 발생할 수도 있다.

이와 마찬가지로 grapgql의 variables도 변수이다.

const CREATE_BOARD = gql`
mutation createBoard($writer: String){
		createBoard(writer: $writer){
			_id
		}
	}
`

위와 같이 $가 붙은 것들은 변해도 괜찮은 변수이다. $writer 대신 $hello가 쓰여도 괜찮다.

🌱 쿼리를 날릴 때 두 번 적어주는 이유
→ 한 요청에서 여러가지의 api요청을 날릴 수 있기 때문

const REQUEST = gql`
mutation 한번에요청할그룹이름 ($변수 : String){
	원하는API1(백엔드지정:$변수){
		//받아올 것
	}

	원하는API2(백엔드지정:$변수){
		//받아올 것
	}
}
`

위와 같이 REQUEST 한번에 여러가지 API를 묶어서 한번에 요청할수 있도록 되어있기때문에 겉에 적어주는 부분은 그룹화를 위한 부분이다 따라서 "한번에요청할그룹이름"의 이름은 중요하지 않고, 백엔드에 보내지는 부분은 내부에 적힌 api들을 보내게 된다.

쉽게 말해 한번의 mutaion에 createProduct와 createBoard를 보낼 수 있다.

---

rest-api의 문제점과 endpoint

우리가 지금 흔히 사용하고 있는 graphql도 사실은 rest-api이다.

기존에 있던 rest-api의 문제점들을 보완하여 만들어진 것이 graphql이다. graphql이 만들어지기 전까지 rest-api를 사용하며 발생했던 다양한 문제들은 아래와 같다.

1. 오버페칭

rest-api는 원하는 데이터만 골라서 가져올 수 없다. 필요없는 결과값까지 모두 받아오는 과정을 오버페칭이라고 한다.

2. 언더페칭

또한 하나의 endpoint에 하나의 body만 들어가기 때문에 여러개의 api를 요청하려면 그만큼 데이터를 요청하는 횟수가 늘어나게 된다. 반면 graphql은 위에 설명한 바와 같이 한 번에 여러개의 api를 요청할 수 있다.
3개의 api가 필요할 경우, 이를 한개씩 여러번 받아오는 것을 언더페칭이라 한다.

endpoint란?
→ API가 서버에서 리소스에 접근할 수 있도록 가능하게 하는 URL

3. 너무 많은 endpoint

graphql이 없던 시절 rest-api를 사용하면서 발생한 가장 큰 문제점이 바로 너무 많은 endpoint가 만들어진다는 점이다. 반면에 graphql은 엔드포인트 통합하여 한 번에 여러가지 요청을 할 수 있음

그래프큐엘의 단점
1. 아직까진 회사에 rest-api사용하는 사람이 더 많음
2. 오픈 api는 대부분이 rest-api
3. graphql은 캐시(임시저장)가 어려움

여러개의 브라우저에서 동일한 데이터를 요청할 경우 첫 요청 때 베이터베이스에서 가져온 데이터를 화면에 띄우기 전 메모리에 저장 후 보여주는걸 캐싱이라고 한다.
하지만 graphql은 주소가 한개이기 때문에 이러한 캐싱이 어렵다. 아예 불가능 한 것은 아니지만 복잡하기 때문에 이러한 단점을 감수하더라도 비용을 효과적으로 줄일 수 있는 큰 서비스를 운영하는 회사에서 주로 사용한다.