GraphiQL의 실패에서 GraphiQL의 장점을 배우다

최근 그래픽QL을 적용한 사례가 늘었다.
한편, 그래픽QL이 제대로 활용되지 않은 경우도 있죠?
이 글에서는 내가 마주친 제대로 이용되지 않은 상황에 대해 어떤 상황인지, 왜 그렇게 됐는지, 그렇게 되지 않도록 어떻게 해야 하는지를 적는다.

모든 Resolver의 독립된 불가사의한 Graph qL

내가 만난 불가사의한 그래프 QL을 한마디로 요약하자면 그래프의 콘셉트 등 없는 마니아 전용 API군이다.
솔직히 이보다 더 잔혹한 건 없을 것 같아...그것보다 다른 개발진이 이런 일을 할 수 있을까?
GraphiQL을 사용할 때 코드 우선의 방법과 패턴 우선의 방법이 있지만 코드 우선의 방법을 선택했기 때문에 빠진 문제라고 할 수 있다.
다음은 간단한 허구를 바탕으로 코드를 우선하는 방법을 실시할 때 발생하는 중대한 문제에 대해 탐구하고자 한다.등장하는 개발 언어는 Type Script입니다.

Enity 정의

여기에는 세 가지 Enity가 있습니다.각각 아래의 구조다.간단하다

class Plan {
  id: ID
  name: string
  price: number
}
class Order {
  id: ID
  planId: string
  quantity: number
  amount: number
  
  plan?: Plan
}
class Shipment {
  id: ID
  orderId: string
  shippingDate: string
  
  order?: Order
}

Enity에서 GraphiQL 모드로 설치

이것을GraphiQL 모드에 넣으면 완성됩니다.

type Plan {
  id: ID!
  name: String!
  price: Float!
}

type Order {
  id: ID!
  planId: ID!
  quantity: Float!
  amount: Float!
  plan: Plan
}

type Shipment {
  id: ID!
  orderId: string
  shippingDate: string
  order: Order
}

Resolver 설치

그런 다음 Enity 에 액세스하는 Resolver 가 있습니다.

상품 상세 정보

주문 상세 정보

상세 정보 보내기

// 実装はなんとなくこういう実装という概念のみ
class PlanResolver {
  // 商品詳細
  async plan(id: ID) {
    const plan: Plan = repository.getPlan(id)
    return plan
  }  
}

class OrderResolver {
  // 注文詳細
  async order(id: ID) {
    const order: Order = repository.getOrder(id)
    return order
  }
}

class ShipmentResolver {
  // 発送詳細
  async shipment(id: ID) {
    const shipment: Shipment = repository.getShipment(id)
    return shipment
  }
}

Reolver에서 Graph QL 모드로 설치

그리고 이 실시에서GraphiQL형을 생성한 결과가 바로 이것이다.

type Query {
  plan(id: !ID): Plan
  order(id: !ID): Order
  shipment(id: !ID): Shipment
}

고객 호출

그리고 고객은 다음과 같은 요구를 할 것이다.

query {
  order(id: orderId) {
    id
    quantity
    plan {
      name
    }
  }
}

문제가 발생했습니다!

프런트엔드 개발자는 "order.plan.name에서 오류가 발생할 수 있습니다"라고 보고했습니다.
사실 이 Query의 성공 여부는 서버의 실현에 달려 있다.
GraphiQL에서는 매번 Relation을 해결해야 한다는 전제가 있습니다.

액세스 주문

주문에서 상품에 대한 접근<- 이 부분

GraphiQL Server는 주문에서 상품에 대한 액세스가 발생하면 주문 대상에 존재하는 값을 반납하거나 주문에서 상품에 대한 해결 처리를 수행하고 반환 값을 반환합니다.
상기 실시 방식에서 주문부터 상품까지의 해결 처리를 실시하지 않았기 때문에 GraphiQL Server는 대상에 존재하는 값만 되돌려줄 수 있다.서버 쪽 처리를 다시 볼게요.

class OrderResolver {
  // 注文詳細
  async order(id: ID) {
    // repository.getOrderで商品情報までまとめて取得しているならQueryは成功するし、
    // 取得していない場合は商品情報はundefinedとなり、Queryは失敗する
    const order: Order = repository.getOrder(id)
    return order
  }
}

객체에 미리 연결된 Enity 형식으로 대응

실복을 수정하여 주문서의 상세한 정보를 얻을 때 상품 정보를 통일적으로 얻습니다.
이렇게 하면 전방 개발자의 의뢰에 대응할 수 있다.

class OrderResolver {
  // 注文詳細
  async order(id: ID) {
    // 注文詳細取得時に、商品情報をまとめて取得
    const order: Order = repository.getOrderWithPlan(id)
    return order
  }
}

추가 주문 요약 Resolver

규격 추가가 발생하여 주문 일람표가 필요합니다.즉시 실시하다.

class OrderResolver {
  // 注文詳細
  async order(id: ID) {
    // 注文詳細取得時に、商品情報をまとめて取得
    const order: Order = repository.getOrderWithPlan(id)
    return order
  }
  
  // 注文一覧 <-- 新しく追加
  async orderList() {
    const orderList: OrderList = repository.getOrderList()
    return orderList
  }
}

문제가 발생했습니다!두 번째

프런트엔드 개발자는 "orderList[number].plan.name에서 오류가 발생할 수 있습니다"라고 보고했습니다.
백엔드 개발자는 주문 일람표를 받을 때 상품 정보를 총괄적으로 얻고 주문서의 상세한 내용을 실시할 때와 같다.

class OrderResolver {
  // 注文一覧
  async orderList() {
    // 注文一覧取得時に、商品情報をまとめて取得
    const orderList: OrderList = repository.getOrderListWithPlan()
    return orderList
  }
}

이상은 내가 만난 불가사의한 GraphiQL 사건이다.이 큐리에서 이 메시지로 거슬러 올라간다', "여기까지 갈 수 있는 큐리 추가를 원한다"등 대화가 오간 상태였다.
여기를 읽은 사람들은 정확한 해결 방법은 주문서부터 상품까지의 해결 처리를 실시하는 것임을 알아차릴 수 있을 것이다.
물론 주문일람표에서 100개의 주문서를 받아 매번 상품에 대한 해결 처리를 하면 처리 효율에 문제가 발생하지만 이용DataLoader을 하면 개선할 수 있다.
처리된 실상+성능을 우려하는 부분은 바로 DataLoader가 대응 제안을 실행했을 것으로 보이지만 "그런데 성능에 신경을 많이 쓰니까..."이후에도 전용 API 클러스터를 계속 제작합니다.강행돌파는 이제 상당히 개선됐지만 여전히 전용 API가 많이 남아있다.

원래 있어야 하는 게 이루어져요.

해결 처리가 이뤄지면 주문 상세내역에서 상품 상세내역을, 주문 일람에서도 상품 상세내역을 확인할 수 있다.
앞으로 발생할 규격 변경도 강해질 것으로 보인다.상품 상세 내역을 보고 싶다고 해도 바로 대응할 수 있을 것 같다.전용 API 방식이라면 어떻게 될까.

class OrderResolver {
  // 注文詳細
  async order(id: ID) {
    const order: Order = repository.getOrder(id)
    return order
  }
  
  // 注文一覧
  async orderList() {
    const orderList: OrderList = repository.getOrderList()
    return orderList
  }
  
  // 商品への解決処理 <-- これを実装すべきだった
  async plan(order: Order){
    const plan: Plan = planRepository.getPlan(order.planId)
    return plan
  }
}

왜 이렇게 됐지

웹API는 3단계를 거쳤다고 해도 과언이 아니다.

1. 전용 API 그룹

Ajax 통신이 시작될 때의 단점은 위에서 말한 GraphiQL과 같은 전용 API 그룹입니다.
관련 정보를 접근할 수 있는지 없는지는 최종 지점에 달려 있다.

2.RESTAPI

이어 외부 API 연합이 보급되면서 레스타피의 사상이 탄생했다.그러나 REST는 통용성이 높지만, 관련 정보에 대한 접근은 반환된 URL에 대해 다시 요청하는 방식이어서 효율적이라고 할 수 없다.가져올 필드도 선택할 수 없습니다.

3. GraphQL

REST 효율성 과제를 해결하는 그래픽QL이 탄생해 보급되고 있다.
이번에 제시한 사업에서 비효율적인 전용 API군을 마련해 대응한 결과 시대에 역행하는 실행이라고 할 수 있다.물론 이런 배경을 이해하지 못하더라도 그래피QL의 공식 문서 등을 잘 읽으면 엔티티 간 해결 처리 실시라는 선택은 반드시 얻을 수 있다.신기술을 정확하게 이해하고 도입하는 것은 어려울 수도 있지만 이를 소홀히 하면 발생하는 비용은 가늠할 수 없다.
나는 GraphiQL을 매우 좋아해서, 그것이 더욱 광범위하게 전파되어 가상이 되기를 바란다.
만약 한 팀이 이 보도에서 언급한 문제를 만났다면, 나는 모두가 GraphiQL의 사상에 정면으로 직면할 수 있기를 바란다.