GraphQL 컨소시엄: 마이크로 서비스가 잘했어.

소개하다.

지금은 모든 사람들이 마이크로 서비스를 하고 싶어 하는 것 같다.gRPC, JSONRPC, GraphQL 등 다양한 스타일의 선택이 쏟아져 나오기 때문에 좋은 구조 결정을 내리기 어렵다.나는 마이크로 서비스가 마이크로 lith로 변하는 것을 자주 본다.나는 누구의 특정한 제약에 대해서도 정확한 답이 있다고 말하는 것이 아니다. 단지 내가 GraphQL을 사용한 경험을 창작하고 나만의 견해를 제시했을 뿐이다.

그래프 - 뭐예요?

GraphQL은 여러 개의 서로 다른 단점의 REST 조회 매개 변수에서 하나의 단점의 JSON 유효 부하로 조회 정보를 옮기는 API 규범이다.(성명의) 묘한 점은 추가 요청 파라미터에 비해 요청에 필요한 정확한 데이터량이 인체공학에 더욱 부합되는 데 있다.
또 다른 장점은 서버와 클라이언트 간의 왕복을 줄이는 것이다.GraphQL은 4개의 요청에 4개의 관련 실체가 아닌 하나의 요청에서 이 실체 간의 관계를 조회하고 되돌려줍니다.특정 정보를 얻기 위해 실체에서 온 정보를 데이터베이스 검색(또는 연결)에 사용할 때 매우 중요할 수 있습니다.
마지막 장점은 강력한 유형화입니다. GraphQL은 요청 모드에 정의된 특정한 필드만 보낼 수 있도록 강요합니다.존재하지 않는 필드를 요청하거나 허위 데이터를 보내면 클라이언트가 오류를 일으킬 수 있으며, 보통 오류가 발생한 부분을 설명할 수 있습니다.

예.

GraphQL이 마이크로 서비스 분야에서의 응용을 토론하기 전에 GraphQL로 전통적인 장면을 디자인하는 것이 매우 중요하다고 생각하고 이를 어떻게 분해하는지 보여 준다.
다음 모드는 대부분의 GraphQL 사용자에게 익숙한 예입니다.

  extend Query {
    me: User
    topProducts(first: Int = 5): [Product]
  }

  type User {
    id: ID!
    name: String
    username: String
    reviews: [Review]
  }

  type Review {
    id: ID!
    body: String
    author: User
    product: Product
  }

  type Product {
    upc: String!
    name: String
    weight: Int
    price: Int
    inStock: Boolean
    shippingEstimate: Int
    reviews: [Review]
  }

여기서, 우리는 평론, 제품, 계좌 사이에 관계가 있는 서비스를 구축하고 있다.어떤 의미에서 보면 계좌, 평론, 제품 공유가 관계를 형성하는 가장자리로 볼 수 있다.예를 들어 우리는 한 제품에 많은 평론이 있다고 말할 수 있지만 평론은 한 제품(일대일)에만 주목한다.
전통적인GraphQL 설정에서, 우리는 플러그인 유형의 해석을 포함하여 모든 종류의 해석 프로그램을 작성할 것이다.
샘플 질의는 다음과 같습니다.

query {
  topProducts(first: 10) {
    name
    weight
    price
    reviews {
      body
      author {
        username
        name
      }
    }
  }
}

전통적인 REST에서, 이것은 세 개의 호출이 필요할 수 있습니다. 하나는 대량의 제품 목록을 가져오고, 다른 하나는 모든 제품의 평론을 가져오고, 다른 하나는 우리를 검색하는 사용자입니다.그다지 이상적이지 않은 REST 구현에는 세 번 이상의 호출이 필요할 수 있습니다.

그런데 웨이보 부분은요?

대형 그림에 대해 아는 것이 있다면, 서로 연결된 구성 요소나 하위 그림으로 분해될 수 있습니다.즉, 공간의 최대 서브집합은 다른 서브맵의 합집합에 덮어쓸 수 없다.
위의 모델을 보면 사용자, 제품, 평론 세 개의 뚜렷한 하위 그림이 있다.어떤 의미에서 보면 서비스 처리 사용자는 자신이 논평(또는 관련 제품)이 있다는 것을 알 책임이 없다.위에 네 번째 숨겨진 하위 grpah - 재고 - 제품의 inStock와 shipping Estimate 필드로 나타납니다.제품 카탈로그를 처리하는 서비스는 창고에서 사용하는 API와 별도로 제공하는 것이 좋습니다.
물론 관심과 독립을 분리하고 확장하는 독립된 서비스로 분해하기를 바랍니다.GraphQL에서는 연방을 사용해 이를 실현할 수 있다.Federation은 하나의 API 게이트웨이 (Federation Gateway라고 함) 가 모든 하위 그림을 조회하여 패턴의 일부분임을 확인하고 비교적 큰 그림으로 봉합할 수 있도록 합니다.이 게이트웨이가 조회를 받았을 때, 지원하는 하위 맵마다 조회의 어느 부분에 서비스를 제공할 수 있는지 확인하고, 모든 서비스에 필요한 조회를 실행할 수 있습니다.어떤 실현에서는 이러한 집행을 병행할 수 있다.
헤어진 후, 이것은 보기에 다음과 같다.
사용자 서비스:

  extend type Query {
    me: User
  }
  type User @key(fields: "id") {
    id: ID!
    name: String
    username: String
  }

제품 서비스:

  extend type Query {
    topProducts(first: Int = 5): [Product]
  }
  type Product @key(fields: "upc") {
    upc: String!
    name: String
    price: Int
    weight: Int
  }

창고 서비스:

  extend type Product @key(fields: "upc") {
    upc: String! @external
    weight: Int @external
    price: Int @external
    inStock: Boolean
    shippingEstimate: Int @requires(fields: "price weight")
  }

검토 서비스:

  type Review @key(fields: "id") {
    id: ID!
    body: String
    author: User @provides(fields: "username")
    product: Product
  }
  extend type User @key(fields: "id") {
    id: ID! @external
    username: String @external
    reviews: [Review]
  }
  extend type Product @key(fields: "upc") {
    upc: String! @external
    reviews: [Review]
  }

서비스가 필드를 원할 때 @external (예를 들어 다른 서비스에서 온 것) 이나 @requires@로 표시합니다.requires는 고객이 필요한 필드(예를 들어 가격, 무게)를 지정하지 않을 수도 있지만 서비스는 이 필드를 통해 출력(예를 들어 출하 추산)을 생성해야 한다는 것을 말한다.

그래, 그런데 왜 이게 쓰레기가 아니야?

내가 보기에 GraphQL은 사람들로 하여금'역'모델과 경계에 따라 사고하기 쉽게 한다.하위 그림은 본질적으로 하나의 경계이다.추가적인 강력한 유형과 가능한 병행 실행은 나의 방법과 기술적 흡인력에 적합하다(Rust)