GraphQL과 해결된 문제를 처음 읽었을 때, 나는 정말 미쳤다.그래서 그래프QL을 알려드리고 싶어요.
이 글에서 나는 GraphQL이 무엇인지, 그리고 GraphQL을 만든 동기가 무엇인지 설명할 것이다.

GraphQL이란 무엇입니까?

GraphQL은 API 구축을 위한 쿼리 언어입니다.그것은 페이스북이 만든 것으로 RESTAPI로 인한 몇 가지 문제를 해결하기 위한 것이다.모바일 페이스북 팀은 휴식에 문제가 생겨 응용 프로그램 성능에 영향을 미쳤다.그들은 간단한 응용 프로그램 페이지에 여러 개의 요청을 실행해야 하며, 데이터 캡처에 과도한 문제가 존재한다.따라서 응용 프로그램의 성능이 영향을 받았다.따라서 그들은 새로운 검색 언어를 만들기 시작했다. 이 언어에서 클라이언트는 어떤 데이터가 필요한지 정확하게 지정하고 하나의 요청에서 그것을 받아들일 수 있다.
2015년 페이스북은 이 언어의 규범을 발표했다.이 규범은 지역사회에서 광범위하게 사용되고 같은 지역사회에서 다양한 언어의 클라이언트와 백엔드를 개발했다. https://graphql.org/code/
현재 GraphQL은 GitHub, Twitter, Airbnb, Atlassian 등 다양한 회사에서 사용되고 있다.

GraphQL은 무엇을 해결했습니까?

이 섹션에서는 GraphQL에서 해결한 REST 문제를 설명합니다.GraphQL의 동기는 이러한 문제를 해결하는 것이기 때문에 그것들을 이해하는 것이 중요하다.

여러 요청

만약 우리가 페이지를 작성하기 위해 약간의 정보가 필요하다고 가정하자.이 페이지에서 우리는 게시물 목록과 관련된 사용자와 평론을 표시하고 싶습니다.

REST API 사용

REST API를 사용하는 경우 페이지에 필요한 모든 정보를 얻기 위해 여러 번 요청할 수 있습니다.

// Get a list of posts - GET
curl https://jsonplaceholder.typicode.com/posts

// Get user of each post -> N request if you have N posts
curl https://jsonplaceholder.typicode.com/users/{post.userId}

// Get comments of each post -> M requests, if each post would have M comments
curl https://jsonplaceholder.typicode.com/comments/${post.comments[i].id}

이 예에서 우리는 중요한 문제를 볼 수 있다.각 게시물에 대해 다음을 수행해야 합니다.
1 - 사용자의 추가 요청을 받습니다.
2 - 댓글에 M개의 댓글이 있는 경우 M은 모든 댓글을 요청합니다.
따라서 우리가 N개의 댓글을 얻었다는 것을 감안하면 각 댓글에는 M개의 댓글이 있다.

totalRequests = 1 (fetch posts)+ N (fetch user) + NM (fetch comments)
totalRequests = 1 + N + NM

예를 들어 만약에 간단한 페이지에 20개의 댓글이 있고 댓글마다 3개의 댓글이 있다면 우리는 모두 1+20+20*3=81개의 요청을 처리할 것이다.
댓글과 댓글 사이의 이 문제는 이미 알려진 문제로 N + 1 problem 라고 한다.간단한 자원 (1개의 요청) 을 얻으면 이 문제가 발생하고, 필요한 모든 정보를 얻기 위해 N개의 요청을 다시 실행해야 합니다.
API의 재구성을 통해 이 문제가 사라진다는 것을 나에게 알려줄 수 있다.이거 진짜야.다음과 같은 새 끝점을 만들면

curl https://jsonplaceholder.typicode.com/posts/1/comments

우리는 모든 댓글에 대한 요청을 실행하기만 하면 모든 댓글을 얻을 수 있다.더 좋은 것은 우리가 댓글 자원에 댓글을 달면 별도의 요청이 필요 없다는 것이다.
그러나 우리는 전방의 수요에 따라 후방을 바꾸어서는 안 된다.이것은 매우 비싸서 우리의 개발 속도를 떨어뜨렸다.

GraphQL 사용

GraphQL을 사용하면 하나의 요청에서만 필요한 모든 데이터를 얻을 수 있습니다.이전 예제와 동일한 GraphQL 질의를 받으려면 다음과 같이 하십시오.

{
 getPosts{
   id
   title
   body
   user {
     id
     username
     avatar
   }
   comments {
     id
     body
     author {
       id
       username
       avatar
     }
   }
 }
}

이 독특한 GraphQL 조회를 통해 필요한 모든 정보를 포함하는 게시물 목록을 얻을 수 있습니다.이것은 휴식에 비해 중요한 우세다.

잡기와 과도한 잡기

앞부분의 예시에 따라 우리는 게시글 목록으로 페이지를 작성해야 한다고 가정한다.이 페이지에서 우리는 모든 게시물의 제목, 사용자 이름, 탭을 표시해야 한다.

REST API 사용

API에 다음 데이터가 포함된 게시물 목록을 반환하는 엔드포인트가 있습니다.

[
{
  id: '1',
  title: 'A title',
  userId: '1',
  tags: ['js', 'html'],
  likes: 12,
  body: 'Post body',
  image: 'An img'
}, 
{...}, 
{...}
]

새 페이지에서는 제목, 사용자 이름, 모든 게시물의 탭만 필요합니다.따라서 우리는 데이터를 과소평가하고 과대평가하고 있음을 알 수 있다.사용자 이름을 얻기 위해 다른 단점을 요청해야 하기 때문에 데이터를 과소평가하고 있습니다.페이지에'body','image','likes'와 같은 속성을 사용하지 않았기 때문에 우리는 과도하게 데이터를 추출합니다.이것은 RESTAPI 문제입니다. 단점이 고정된 데이터 구조를 되돌려주기 때문입니다.따라서 우리가 단점에 도달했을 때, 복구된 데이터는 우리가 필요로 하는 것보다 더 많거나 더 적은 정보를 포함할 수 있다.

GraphQL 사용

GraphQL을 사용하면 클라이언트가 원하는 데이터를 정확하게 지정할 수 있습니다.따라서 우리는 데이터 추출 부족과 과도한 추출 문제가 존재하지 않을 것이다.예제 질의는 다음과 같습니다.

{
 getPosts{
   id
   title
   tags
   user {
     username
   }
 }
}

그리고 단일 조회를 통해 우리는 데이터의 추출 부족과 과도한 추출을 피하기 위해 필요한 정확한 정보를 얻을 것이다.

프런트엔드와 백엔드 결합

응용 프로그램에서 새 페이지를 개발하고 있다고 가정하십시오.우리가 필요한 데이터를 분석할 때, 우리는 모든 데이터를 얻기 위해 여러 개의 RESTAPI 단점을 호출해야 한다고 결정합니다.
여러 API 요청으로 인해 어플리케이션의 성능에 영향을 주지 않으려면 REST API 노드를 변경하거나 새 노드를 만들 수 있습니다. 이 노드는 하나 이상의 노드 페이지에 필요한 모든 데이터만 되돌려줍니다.이런 상황은 RESTAPI에서 자주 발생하는데, 우리는 일반적으로 API를 변경할지 아니면 앞부분을 API가 제공하는 정보에 적응시키는지 결정해야 한다.이것은 문제입니다. 왜냐하면 우리는 전단과 후단을 결합하고 있기 때문입니다.
GraphQL이 있으면 이 문제는 사라집니다.클라이언트는 백엔드의 내용을 변경하지 않고 모든 페이지에서 필요한 데이터를 얻을 수 있습니다.클라이언트는 GraphQL API 모드만 알고 있어야 합니다.GraphQL 모드는 API가 제공하는 데이터를 정의하고 클라이언트가 필요에 따라 사용할 수 있습니다.

프런트엔드와 백엔드 간의 계약 부족

REST는 클라이언트와 서버의 통신 방식을 정의했지만 클라이언트와 서버 간에 교환되는 정보에 대한 데이터 구조에 대한 내용은 정의하지 않았다.데이터 구조에 대한 결정은 개방적이다. 일반적으로 백엔드는 클라이언트와 어떻게 정보를 보내고 수신하는지를 결정한다.조직적인 팀에서 프런트엔드와 백엔드 팀은 API의 단점과 데이터 구조를 일치시킬 수 있다.어쨌든 이것은 RESTAPI의 특징이 아니라 조직이 좋은 팀의 특징이다.외부 REST API를 사용해야 하는 다른 많은 상황에서 우리는 API를 사용하기 전에 데이터 구조를 모른다.
GraphQL은 강력한 유형의 시스템을 사용하여 데이터 구조를 정의하고 클라이언트에서 사용할 수 있는 정보를 해결하는 문제를 해결했다.이 모든 정의는 GraphQL 모드 정의 언어(SDL)를 사용하여 모드에 작성됩니다.예:

type Post {
  id: ID!
  title: String!
  body: String!
  user: User!
  comments: [Comment]
}

type Comment {
  id: ID!
  body: String!
  user: User!
}

type User {
  id: ID!
  username: String!
  avatar: String
}

type Query {
  getPosts: [Post]
  getUsers: [User]
}

이 모델은 클라이언트와 서버 간의 계약을 충당한다.
GraphQL 모드가 정의되면 프런트엔드와 백엔드 팀은 계약이 있기 때문에 독립적으로 작업할 수 있습니다.따라서 전단팀은 모델에 따라 데이터를 시뮬레이션하고 전체 전단 응용 프로그램이나 웹 페이지를 개발할 수 있다.백엔드가 준비되면 프런트엔드 팀은 진정한 GraphQL API를 사용할 수 있습니다.

문서 없는 API

REST는 API에 대한 문서를 만들도록 강요하지 않습니다.개발자가 RESTAPI 문서를 만드는 데 도움을 줄 수 있는 Swagger 같은 도구가 있습니다.그러나 개발자들은 그것을 만들고 유지하기 위해 별도의 노력을 기울여야 한다.따라서 많은 RESTAPI에 문서가 없거나 오래된 문서가 있습니다.
GraphQL은 강력한 유형의 시스템을 사용하기 때문에 정의에 따라 문서 기록이 있는 언어입니다.따라서 API 문서는 GraphQL 모드를 만들어야 생성할 수 있습니다.예를 들어, 위의 패턴이 포함된 gif 문서입니다.

API 사용 추적 부족

REST에서 클라이언트가 API를 어떻게 사용하는지 추적할 수 있는 유일한 방법은 각 노드가 호출되는 빈도입니다.
GraphQL을 사용하면 모든 클라이언트가 관심 있는 정보를 정확하게 지정할 때 사용 중인 데이터와 사용하지 않은 데이터를 알 수 있습니다.또한 API 성능에 대한 중요한 견해는 요청된 각 속성의 성능을 측정할 수 있습니다.

결론

우리는 GraphQL과 GraphQL이 REST에 비해 어떤 장점을 가지고 있는지 이미 이해했다.
GraphQL은 강력한 도구이지만 실버블릿은 아닙니다.API REST 구축은 더 간단할 수 있습니다.따라서 만약에 제가 본고에서 언급한 REST 문제에 관심이 없다면 REST는 당신의 프로젝트의 좋은 선택입니다.
읽어주셔서 감사합니다!