GraphiQL과 Apollo Client의 불협화음 오류

REST API를 대체하는 API 표준으로 보급 중인 GraphiQL.
주로 리액트에서 사용된 이미지로, Vue에도 대응할 수 있는 프로그램 라이브러리가 있기 때문에 최근에는 Vue Apollo+Composition API의 조합으로 개발됐다.나는 상당히 좋아한다.
다만, 사용 과정에서 어떻게든 신경 쓰이는 것은'그래픽 QL과 아폴로 클라이언트 콘셉트, 모순되지 않나?'보고 싶어서 써 봤어요.
※ 전혀 믿을 수 없는 내용일 수도 있지만, 전반적으로 고민을 상의하는 느낌일 수도 있으니 잘못이 있다면 꼭 지적해 주세요!
※ 4/10 추기: 댓글@necocoa에서 GraphiQL/Apollo Client/GraphiQL Code Generator의 정확한 사용법을 알려주셨습니다.기사의 내용을 수정하려면 전편을 다시 써야 하기 때문에 제목을 제외하고는 초고 상태가 유지되기 때문에'이런 느낌의 초보자도 있구나'라는 시각으로 읽고 댓글을 꼭 확인해 주세요.

TL;DR

GraphiQL에서 원하는 값만 지정하면 같은 모델이라도 쿼리별로 TypeScript의 유형을 구분해야 한다

흐려짐

Apollo Client 캐시 데이터 중 어느 값을 유지)

자동으로 생성되는 유형을 활용하려면 REST API처럼 모든 값을 얻을 수 있잖아

GraphiQL의 특징

우선,GraphiQL의 어떤 우수성에 관하여.
GraphiQL의 특징 분해~API 인터페이스 Universal BFF·API Gateway~Qiita
위의 문장을 참고하여 주로 앞부분에서 활용한 장점으로 쓰면 스스로 정리해 보세요.

클라이언트의 데이터를 자유롭게 지정

클라이언트 측에서 필요한 데이터를 지정할 수 있으므로 서버 측에서 추가 개발, 불필요한 데이터 반환, 종단점 추가

필요 없음

요청에 필요한 정보를 한꺼번에 얻을 수 있음

Type Script와 잘 어울립니다.

서버 측에서 정의한 Schema는 문서가 됩니다

.

Schema에서 유형 정의를 자동으로 생성할 수 있음

Apollo Client 우수

Apollo Client 자체 캐시 관리 기능(Vuex 및 Redux 교체 가능)

TypeName과 ID에 따라 자동으로 차이점을 업데이트할 수 있기 때문에 "mutation으로query가 얻은 배열 데이터의 일부분을 업데이트했을 때"에서query를 다시 얻거나 스스로 바꿀 필요가 없음

이러한 장점은 모두 기존 REST API의 문제점에 대한 답변으로 풍부하다.
나도 몇 달 동안 GraphiQL을 써 보았는데 대체적으로 이 장점을 즐겼고 REST API보다 더 편리하다고 느꼈다.
하지만 사용 과정에서 문제가 생겼다.

query에 필요한 매개 변수만 지정하면 Schema에서 자동으로 생성된 유형과 일치하지 않습니다

예를 들어 블로그의 글은 다음과 같은 Schema로 정의한다.

type Post {
  id: ID!
  category: String
  body: String!
  user: User!
  createdAt: Date!
  updatedAt: Date!
}

이 Schemagraphql-codegen를 사용하여 Type Script용 유형을 자동으로 생성할 때는 다음과 같습니다.

export type Post = {
  __typename?: 'Post'
  id: Scalars['ID']
  category?: Maybe<Scalars['String']>
  body: Scalars['String']
  user: User
  createdAt: Scalars['Date']
  updatedAt: Scalars['Date']
}

여기는 category만undefined가 있을 가능성이 있다.
그러나 실제로GraphiQL의query가 지정한 값을 얻지 못했기 때문에

gql`
  query Posts {
    posts {
      id
      category
      body
    }
  }
`

이러한 조회를 통해 얻은 데이터에 자동으로 생성된 포스트형을 적용할 수 없습니다.자주 존재하는createdAt는undefined이기 때문이다.적용 가능하지만 런타임 오류가 발생할 위험이 있습니다. implements Partial<Post> 이렇게 스스로 새롭게 정의할 수 있지만 조회에 따라 다시 쓰면 자동으로 생성되는 이점을 받지 못할 것 같다.

모든query가 요구하는 조회가 다르면 차별 업데이트는 부분적으로만 작용할 수 있습니다

예를 들어 WordPress의 관리 화면처럼 화면을 일람하고 편집할 수 있다
일람 화면에서 글을 선택하고 편집 화면에서mutation을 사용하여 업데이트한 후 일람 화면으로 돌아갑니다.

gql`
  mutation updatePost (input: $post) {
    post {
      id
      category
      body
    }
  }
`

이 화면에 필요한 조회를 한 번 받았습니다. 편집된 글은mutation의 반환값으로 자동으로 업데이트되기 때문에 화면을 다시 한 번 볼 때GraphiQL에 접근할 필요가 없습니다.
그러나 이때의 mutation에 지정된 값이 없으면 고객이 호출하지 않기 때문에 화면을 일람할 때'mutation 업데이트 후의 내용을 반영한 키'와'mutation 업데이트 전에 얻은 내용을 유지하는 키'가 혼합될 수 있다.
(뒤에서 가져온 데이터에 부족한 값이 있으면 캐시와 통합하는 것이 기본값이기 때문에 사라지지 않습니다.)
이 문제는 판단할 수 없는 것이냐?
"mutation은 업데이트 작업이기 때문에 작업에 따라 변경된 값을 모두 얻어야 한다"는 생각일 수도 있어요.
개인 블로그라면 따로 논할 필요가 없다. 한 번에 편집하는 값이 20개 이상이면 누락될 수 있다
'어떤 속성에 영향을 미치는지 판단하기 위한 조작'은 버그의 온상이 될 수 있으며, 장래에 변경이 발생할 경우 업데이트를 잊어버려도 자동으로 발견할 수 없습니다.
뮤테이션이라면 괜찮은데query 간이라면'페이지 A에는 세금 포함 금액을 사용하고 페이지 B에는 세금 포함 금액만 사용한다'는 식으로 취득 순서가 달라 세금과 세금 제외도 편차가 있다.

편하긴 한데..

상술한 문제를 확실히 회피하는 방법으로 자신이 현재 진행하고 있는 것은 같은 데이터 모델에 대해query·mutation은 항상 모든 값을 얻는다.
항상 모든 키를 지정하면 자동으로 생성된 형식을 직접 사용할 수 있고query에 따라 차이가 생기지 않습니다.
...하지만 이 사용법은 쓰기만 다르면 기본적으로 REST API이다.
Apollo Client 는 확실히 매우 편리합니다. 설령 이 용법 이라도 REST API 의 상위 호환성 의 힘 을 느낄 수 있습니다
Apollo Client를 활용하려면 GraphiQL이 필요 없고, GraphiQL을 활용하려면 Apollo Client를 사용하지 않는 것이 좋다.
서버 측은 하나의 종점이 필요하지 않기 때문에 개발 효율이 높아집니다. 이런 상하문이라면 이해할 수 있습니다.
'필요한 값만 취하면 통신을 고속화할 수 있다'는 장점에 대해 정말 누군가가 활용한 것일까?이것은 의문이다.
다들 그거 쓰나?아니면 Vue Apollo가 아닌 React였다면 이런 문제가 발생하지 않았을 텐데...?
아무튼, 뭔가 빠뜨린 게 아닐까, 아니면 그래픽QL의 진정한 힘을 발휘하지 못한 것 같으니 더 좋은 사용법을 아는 사람이 있으면 꼭 알려주세요.상세한 사람의 평론을 기대하고 있다.