GraphQL 캐싱 작업

GraphQL 캐시 메커니즘 분석 : 캐시 오류 파괴

"GraphQL은 캐싱을 지원하지 않는다"또는 "Caching에 관심이 없다"와 같은 내용에 대해 들었을 것입니다. 이것은 많은 사람들에게 큰 문제입니다. 그러나 그것은 사실이 아닙니다. GraphQL의 공식 문서는 다양한 캐싱 기술을 언급하며, 이는 개발 팀이 캐싱 및 성능 장점에 큰 중요성을 부여 함을 보여줍니다.

이 기사는 GraphQL과 캐시의 관계를 명확히하고 다양한 캐싱 기술과 캐시를 사용하여 GraphQL 쿼리를 최적화하는 방법을 도입하는 것을 목표로합니다.

GraphQL 자동 캐싱 메커니즘

게시물과 저자를 얻으려면 다음 쿼리를 고려하십시오.

 쿼리 getpost {
  Post (슬러그 : "Working-with-graphql-caching") {
    ID
    제목
    작가 {
      ID
      이름
      화신
    }
  }
}

GraphQL 자동 캐싱을 구현하기위한 "비밀"은 __typename 메타 필드이며 모든 GraphQL API에 의해 제공됩니다. 이름에서 알 수 있듯이 __typename 객체의 유형 이름을 반환합니다. 이 필드는 기존 쿼리에 수동으로 추가 할 수 있으며, 대부분의 GraphQL 클라이언트 또는 CDN은 URQL과 같이 자동으로 추가됩니다. 서버에서받은 쿼리는 다음과 같습니다.

 쿼리 getpost {
  Post (슬러그 : "Working-with-graphql-caching") {
    __typename
    ID
    제목
    작가 {
      __typename
      ID
      이름
    }
  }
}

__typename 포함하는 응답은 다음과 같습니다.

 {
  데이터 : {
    __typename : "post",
    ID : 5,
    제목 : "GraphQL 캐싱 작업",
    작가: {
      __typename : "사용자",
      ID : 1,
      이름 : "Jamie Barton"
    }
  }
}

__typename 은 GraphQL 캐시의 핵심입니다. 결과를 캐시하고 Post ID 5 및 사용자 ID 1이 포함되어 있음을 알 수 있기 때문입니다.

Apollo 및 Relay와 같은 라이브러리는 자동 캐싱을위한 특정 수준의 내장 캐싱을 제공합니다. 그들은 이미 캐시에 무엇이 있는지 알고 있으므로 원격 API 대신 캐시를 활용하여 클라이언트가 쿼리에서 요청하는 것을 얻을 수 있습니다.

자동 고장 캐시

Post 작성자가 editPost 변형을 사용하여 게시물의 제목을 수정한다고 가정합니다.

 돌연변이 {
  editPost (입력 : {id : 5, 제목 : "그래프 QL 캐싱 작업"}) {
    ID
    제목
  }
}

GraphQL 클라이언트가 __typename 필드를 자동으로 추가 하므로이 변형의 결과는 즉시 게시물 ID 5가 변경되었으며 게시물이 포함 된 캐시 된 쿼리 결과가 무효화되어야한다는 캐시에 즉시 알려줍니다.

 {
  데이터 : {
    __typename : "post",
    ID : 5,
    제목 : "GraphQL 캐싱 작업"
  }
}

다음에 사용자가 동일한 쿼리를 보낼 때 쿼리는 캐시에서 만료 된 결과를 사용하는 대신 소스에서 새 데이터를 얻게됩니다.

GraphQL 캐시를 정규화합니다

많은 GraphQL 클라이언트가 전체 쿼리 결과를 캐시하지 않습니다. 대신 캐시 된 데이터는 두 개의 데이터 구조로 정규화합니다. 하나는 각 객체를 데이터와 연관시킵니다 (예 : 게시물 #5 :…}, 사용자 #1 : {…} 등)는 각 쿼리가 포함 된 개체 (예 : getpost : {post #5, user #1} 등).

특정 예제 및 사용 사례에 대해 캐싱 정규화 또는 아폴로의 "탈신 캐시 정규화"에 대한 URQL 문서를 참조하십시오.

그래프 QL 캐시 에지 케이스

GraphQL 캐시가 자동으로 처리 할 수없는 메인 엣지 케이스 중 하나는 목록에 항목을 추가하는 것입니다. 따라서 createPost 돌연변이가 캐시를 통과하는 경우 항목을 추가 할 특정 목록을 알지 못합니다.

가장 쉬운 "해결 방법"은 돌연변이에서 부모 유형을 쿼리하는 것입니다 (존재하는 경우). 예를 들어, 다음 쿼리에서 게시물의 커뮤니티 관계를 쿼리합니다.

 쿼리 getpost {
  Post (슬러그 : "Working-with-graphql-caching") {
    ID
    제목
    작가 {
      ID
      이름
      화신
    }

    # 또한 게시물의 커뮤니티를 쿼리하십시오
    지역 사회 {
      ID
      이름
    }
  }
}

그런 다음 createPost 변형에서 커뮤니티를 쿼리하고 커뮤니티가 포함 된 캐시 된 쿼리 결과를 무효화 할 수 있습니다.

 돌연변이 생물 {
  CreatePost (입력 : {...}) {
    ID
    제목

    # 또한 게시물 커뮤니티를 쿼리하여 무효화합니다.
    지역 사회 {
      ID
      이름
    }
  }
}

완벽하지는 않지만 타이핑 된 패턴과 __typename metafields는 Caching에 GraphQL API를 훌륭하게 만드는 열쇠입니다.

이 모든 것이 스톱 갭 솔루션이라고 생각할 수 있으며 GraphQL은 여전히 ​​기존 캐싱을 지원하지 않습니다. 당신은 틀릴 수 없습니다. GraphQL은 게시물 요청을 통해 실행되므로 응용 프로그램 클라이언트를 제거하고 위에서 언급 한 "트릭"을 사용하여 GraphQL의 최신 브라우저 캐시를 활용해야합니다.

그러나이 접근법이 항상 가능하지는 않으며 클라이언트 캐시를 관리하는 가장 좋은 방법은 아닙니다. 더 어려운 경우에 GraphQL 클라이언트는 캐시를 수동으로 업데이트해야하지만 GraphCDN과 같은 서비스는 "서버와 같은"캐싱 경험을 제공하고 더 나은 캐싱 제어를 위해 다음을 수행 할 수있는 수동 지우기 API를 제공합니다.

 # 특정 객체의 모든 발생을 제거하십시오
돌연변이 {
  PurgeUser (ID : [5])
}

 # 쿼리 이름으로 퍼지
돌연변이 {
  _purgequery (쿼리 : [ListUsers, ListPosts]))
}

 # 유형의 모든 발생을 제거하십시오
돌연변이 {
  퍼지저서
}

이제 GraphCDN 엔드 포인트를 어디에서 사용하든 더 이상 모바일, 웹 등과 같은 모든 클라이언트 로직에서 캐시 정책을 다시 구현할 필요가 없습니다. Edge Caching은 API를 매우 빠르게 만들고 사용자 간의 캐시를 공유하고 각 사용자의 클라이언트와 분리하여로드를 줄입니다.

최근에 클라이언트 나 서버에서 캐시 구성을 처리하는 데 도움이되는 프로젝트에서 GraphCDN을 사용하여 프로젝트를 계속할 수있었습니다. 예를 들어, 엔드 포인트를 GraphCDN으로 바꾸고 쿼리 복잡성 (곧), 분석 등을 무료로 얻을 수 있습니다.

그렇다면 GraphQL은 캐싱에 관심이 있습니까? 물론 당신은 관심이 있습니다! 일부 내장 자동 캐싱 방법을 제공 할뿐만 아니라 많은 GraphQL 라이브러리는 캐싱을 구현하고 관리하는 다른 방법을 제공합니다.

이 기사가 GraphQL 캐싱 메커니즘을 이해하고 클라이언트 측에서이를 구현하는 방법과 CDN을 활용하여 모든 작업을 수행하는 방법을 이해하는 데 도움이되기를 바랍니다. 내 목표는 모든 프로젝트에서 GraphQL을 사용하도록 설득하지는 않지만 쿼리 언어를 선택하고 캐싱이 중요한 요소라면 GraphQL 이이 작업에 완벽하게 유능하다는 것을 알고 있습니다.

위 내용은 GraphQL 캐싱 작업의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!