들어가기
한 달 동안 진행되었던 고랭 알고리즘 스터디가 팀원 분들이 시간이 안 되는 관계로 끝났다
4월에 다시 하자는 말이 있었는데
한다면 난 하면 할 것 같은데, 과연 다시 시작할지는 모르겠다
그동안 문제 풀고 그걸 블로그에 글로 추가함으로써 뭐 쓸지 고민 안 해도 돼서 편했는데
이제 주제를 다시 정해야 될 때가 와버렸다..
주제 선정에 고민하다가 문뜩 GPT가 기억났다,
그래서 한번 물어봤는데
역시 대단한 친구라 그런지 여러 가지 답변을 줬는데
그중에서 눈에 들어온 친구가 있었다
오? GraphQL?
어디선가 많이 본 친구가 보였고 이김에 이거로 하기로 마음을 먹었고
관련해서 좀 알아보면 아래 세 개로 정의할 수 있다
- API를 쿼리로 사용하는 언어이다
- 페이스북(Facebook)에 의해 2012년 내부적으로 개발되었고, 2015년에 공개되었다
- 기존에 고정된 End Point를 가지는 REST API의 단점을 해소했다
REST API의 단점이 있어?
REST API는 가장 친근한 API로 사용하기 쉬운데 무슨 단점이 있을까 했는데찾아봐서 나온 아래 단점들이 수긍이 갔다
- 오버패칭(Over-fetching): 클라이언트가 필요한 것보다 많은 데이터를 받게 되는 경우.
- ex) 사용자 이름만 필요한 상황에서 사용하지 않는 주소, 전화번호, 가족관계 등등 여러 가지가 같이 추가 데이터가 딸려오는 경우
- 언더패칭(Under-fetching): 오버패칭이랑 반대로 필요한 것보다 데이터가 부족한 경우
- ex) 사용자 이름과 직장 정보가 필요한 상황에서 직장 정보는 사용자 정보와 같이 얻을 수 없는 경우
- End Point 관리의 복잡성: 애플리케이션이 커지면서 이제 관리해야 할 End Point가 많아진 경우
- ex) API 문서를 봐야지만 겨우 End Point를 찾을 수 있는 경우 또 그렇게 되면 API 문서 관리에도 자원이 들어가게 되는데 그것도 단점이라 볼 수 있다
그래서 GraphQL는 어떻게 하는데?
RestAPI는 서버에서 정의한다면 GraphQL는 클라이언트가 정의한다고 생각하면 된다
클라이언트가 원하는 걸 바로 받을 수 있게 해주는 API이다
- 정확한 데이터 요청: 클라이언트는 필요한 데이터의 구조를 쿼리로 명시할 수 있으며, 서버는 그에 따른 맞춤형 데이터를 준다 (GraphQL은 Query를 통해 데이터를 가져온다 그래서 QL이 붙는다 = Graph + Query Language)
- 단일 엔드포인트: GraphQL은 단일 엔드포인트를 통해 모든 데이터 요청을 처리합니다. 이걸로 RestAPI의 End Point 복잡성 및 관리를 줄여주고 API 구조를 단순화해준다
- 타입 시스템: GraphQL은 강력한 타입 시스템을 제공하여, API를 통해 교환되는 데이터의 형식과 구조를 명확히 정의하는데 이걸로 보다 안정적이고 예측 가능하게 데이터를 다룰 수 있다
페이스북 개발자들은 아무래도 복잡한 데이터 구조와 대규모 사용자를 관리할 때
복잡함에 따른 비용 증가를 해결하기 GraphQL을 만든 듯 하다
다음에는 Go로 GraphQL 만들기로 봅시다
들어가기
한 달 동안 진행되었던 고랭 알고리즘 스터디가 팀원 분들이 시간이 안 되는 관계로 끝났다
4월에 다시 하자는 말이 있었는데
한다면 난 하면 할 것 같은데, 과연 다시 시작할지는 모르겠다
그동안 문제 풀고 그걸 블로그에 글로 추가함으로써 뭐 쓸지 고민 안 해도 돼서 편했는데
이제 주제를 다시 정해야 될 때가 와버렸다..
주제 선정에 고민하다가 문뜩 GPT가 기억났다,
그래서 한번 물어봤는데
역시 대단한 친구라 그런지 여러 가지 답변을 줬는데
그중에서 눈에 들어온 친구가 있었다
오? GraphQL?
어디선가 많이 본 친구가 보였고 이김에 이거로 하기로 마음을 먹었고
관련해서 좀 알아보면 아래 세 개로 정의할 수 있다
- API를 쿼리로 사용하는 언어이다
- 페이스북(Facebook)에 의해 2012년 내부적으로 개발되었고, 2015년에 공개되었다
- 기존에 고정된 End Point를 가지는 REST API의 단점을 해소했다
REST API의 단점이 있어?
REST API는 가장 친근한 API로 사용하기 쉬운데 무슨 단점이 있을까 했는데찾아봐서 나온 아래 단점들이 수긍이 갔다
- 오버패칭(Over-fetching): 클라이언트가 필요한 것보다 많은 데이터를 받게 되는 경우.
- ex) 사용자 이름만 필요한 상황에서 사용하지 않는 주소, 전화번호, 가족관계 등등 여러 가지가 같이 추가 데이터가 딸려오는 경우
- 언더패칭(Under-fetching): 오버패칭이랑 반대로 필요한 것보다 데이터가 부족한 경우
- ex) 사용자 이름과 직장 정보가 필요한 상황에서 직장 정보는 사용자 정보와 같이 얻을 수 없는 경우
- End Point 관리의 복잡성: 애플리케이션이 커지면서 이제 관리해야 할 End Point가 많아진 경우
- ex) API 문서를 봐야지만 겨우 End Point를 찾을 수 있는 경우 또 그렇게 되면 API 문서 관리에도 자원이 들어가게 되는데 그것도 단점이라 볼 수 있다
그래서 GraphQL는 어떻게 하는데?
RestAPI는 서버에서 정의한다면 GraphQL는 클라이언트가 정의한다고 생각하면 된다
클라이언트가 원하는 걸 바로 받을 수 있게 해주는 API이다
- 정확한 데이터 요청: 클라이언트는 필요한 데이터의 구조를 쿼리로 명시할 수 있으며, 서버는 그에 따른 맞춤형 데이터를 준다 (GraphQL은 Query를 통해 데이터를 가져온다 그래서 QL이 붙는다 = Graph + Query Language)
- 단일 엔드포인트: GraphQL은 단일 엔드포인트를 통해 모든 데이터 요청을 처리합니다. 이걸로 RestAPI의 End Point 복잡성 및 관리를 줄여주고 API 구조를 단순화해준다
- 타입 시스템: GraphQL은 강력한 타입 시스템을 제공하여, API를 통해 교환되는 데이터의 형식과 구조를 명확히 정의하는데 이걸로 보다 안정적이고 예측 가능하게 데이터를 다룰 수 있다
페이스북 개발자들은 아무래도 복잡한 데이터 구조와 대규모 사용자를 관리할 때
복잡함에 따른 비용 증가를 해결하기 GraphQL을 만든 듯 하다
다음에는 Go로 GraphQL 만들기로 봅시다
