Skip to content

Latest commit

 

History

History
106 lines (83 loc) · 4.28 KB

쿼리_뮤테이션.md

File metadata and controls

106 lines (83 loc) · 4.28 KB

Query

별칭

눈썰미가 좋으신 분들은 알아차리셨겠지만, 결과 객체 필드가 ​​쿼리의 필드 이름과 일치하지만 인자는 그렇지 않으므로 다른 인자를 사용하여 같은 필드를 직접 쿼리 할 수는 없습니다. 그렇기 때문에 필드의 결과를 원하는 이름으로 바꿀 수 있습니다. 이 것이 별칭 이 필요한 이유입니다.

{
  empireHero: hero(episode: EMPIRE) {
    name
  }
  jediHero: hero(episode: JEDI) {
    name
  }
}

위 예제에서 두 hero 필드는 서로 충돌하지만, 서로 다른 이름의 별칭을 지정할 수 있으므로 한 요청에서 두 결과를 모두 얻을 수 있습니다.

프래그먼트

앱에서 상대적으로 복잡한 페이지가 있다고 가정해 봅시다. 친구(friends)를 가진 두 영웅(hero)을 순서대로 요청한다고 해봅시다. 그러면 쿼리가 복잡해질 수 있습니다. 이렇게되면 필드를 최소 두 번 반복해야합니다.

이것이 프래그먼트 라는 재사용 가능한 단위가 GraphQL에 포함된 이유입니다. 프래그먼트를 사용하면 필드셋을 구성한 다음 필요한 쿼리에 포함시킬 수 있습니다. 다음은 프래그먼트을 사용하여 위 상황을 해결하는 방법의 예제입니다.

{
  leftComparison: hero(episode: EMPIRE) {
    ...comparisonFields
  }
  rightComparison: hero(episode: JEDI) {
    ...comparisonFields
  }
}
​
fragment comparisonFields on Character {
  name
  appearsIn
  friends {
    name
  }
}

필드가 반복될 경우 위 쿼리가 꽤 반복될 것을 알 수 있습니다. 프래그먼트 개념은 복잡한 응용 프로그램의 데이터 요구사항을 작은 단위로 분할하는데 사용됩니다. 특히 청크가 다른 여러 UI 구성 요소를 하나의 초기 데이터 fetch로 통합해야하는 경우에 많이 사용됩니다.

변수

query Hero($episode: Episode, $withFriends: Boolean!) {
  hero(episode: $episode) {
    name
    friends @include(if: $withFriends) {
      name
    }
  }

{
  "episode": "JEDI",
  "withFriends": false
}
  • @include(if: Boolean): 인자가 true 인 경우에만 이 필드를 결과에 포함합니다.
  • @skip(if: Boolean) 인자가 true 이면 이 필드를 건너뜁니다.

Mutation

  • GraphQL도 마찬가지입니다. 기술적으로는 어떠한 쿼리든 데이터를 수정할 수도 있습니다. 하지만 변경을 발생시키는 작업이 명시적으로 뮤테이션를 통해 전송되어야 한다는 규칙을 정하는 것이 좋습니다.

  • 쿼리 필드는 병렬로 실행되지만 뮤테이션 필드는 하나씩 차례대로 실행됩니다.

    • 즉, 하나의 요청에서 두 개의 incrementCredits 뮤테이션를 보내면 첫 번째는 두 번째 요청 전에 완료되는 것이 보장됩니다.

인라인 프래그먼트

query HeroForEpisode($ep: Episode!) {
  hero(episode: $ep) {
    name
    ... on Droid {
      primaryFunction
    }
    ... on Human {
      height
    }
  }
}
  • 인터페이스나 유니언 타입을 반환하는 필드를 쿼리하는 경우, 인라인 프래그먼트 을 사용해야합니다. 예제를 통해 확인하는 것이 가장 쉽습니다.

질문

  • 프래그먼트를 사용하면 조합해서 클라이언트가 요청을 보낼 수 있는데, 서버는 resolver로 그럼 복잡하게 구조를 만들어줄 필요가 없는건가? 서버는 엔티티만 정의해두고, 클라이언트는 필요한 데이터를 조합해서 요청을 보내고

    • 이럴 경우 네트워크 효율은 있지만, 서버 측에서는 계속 1+n 쿼리 요청 된다.

  • 만약 1+n쿼리를 요청하는 경우 nosql lookup이나, mysql join없이도 1번의 리퀘스트로 해결 가능하지는 않구나(네트워크 1, 쿼리는 1+n)

  • graphql은 변수를 어떻게 저장할 수 있는가? 언어별로 구현되어있다.

  • 리졸버 이름을 짓는 베스트 프랙티스는 뭘까? (예시에서는 HeroNameAndFriends, mutation CreateReviewForEpisod 이런식으로 지었던데)

  • 자바스크립트의 변수값을 grapqhl 스키마 변수로 바로 할당 가능한가? ㅇㅇㅇ

  • 인라인 프래그먼트의 ... on <타입>은 if exist같은 걸까

dataloader vs mongoose populate

https://stackoverflow.com/a/52669965