https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
안녕하세요. 초보적인 질문인데요, 제가 grphql을 ’ 효율적 ' 으로 사용하고 있는가에...
# 질문
z
안녕하세요. 초보적인 질문인데요, 제가 grphql을 ’ 효율적 ' 으로 사용하고 있는가에 대해 의문이 들었습니다. 최근에 겪은 어려움이 하나의 조건을 만들기 위해 필드의 뎁스가 깊고, 필요한 필드의 스코프?가 다르고, 또 한 리스트 필드를 전부 조회하면서 또 다른 api를 날리며 조건을 만들다보니 전혀 효율적으로 느껴지지 않습니다. 백엔드팀에게 개선요청했으나, graphql은 필요한 데이터만 뽑아쓰고, 필터링 할 수 있기때문에 프론트에서 가공하는게 맞다. 라고하시는데 한 페이지를 그리기위해 이렇게까지 해야하나요? 데이터를 가져올때 필터링하는 것도 한계가 있는거같아요. 한 필드에대해 하나의 조건을 달아줄뿐이라고 느껴져요. 애초에 데이터를 가져올 때, 필터링을 어디까지 사용할 수 있는지 모르겠어요. 또 리스트필드를 조회하면서 api를 날리는게 프론트에서 할 수 밖에 없는 일인지, 필터링할때 깔끔하게 가져올 수 없는지 답답합니다. 제가 어떤 부분을 참고해서 개선하면 좋을지 조언부탁드립니다ㅜㅜ
Copy code
아래의 query를 다음과 같은 조건으로 가공하고싶습니다.

  # 1. status가 true (!isDog 일때는, dogTypes의 status로 필터링)
  # 2. isDog 일때, dogTypes 으로 필터링
  # 3. !isDog 일때, catTypes, catInfo로 필터링
  # 4. isSent가 false
  # 5. [number]를 조회하면서, 각각에대해 외부 api를 연동해서 결과가 true
  # 6. 5번이 true이였을 시점의 시간으로부터 하루 이내

  query Pets {
    pets {
      id
      isDog
      status
      catTypes {
        id
        isSent
      }
      catInfo {
        id
        number
      }
      dogTypes {
        status
        dogInfo {
          isSent
          number
        }
      }
    }
  }
👀 2
👍 1
h
지금 사용하고 계신 쿼리 예시가 있으면 더 답변이 수월할 것 같습니다
z
넵, 이 정도 예시면 될까요ㅜㅜ
h
스키마가 추상화 단위가 잘 이해가 안되긴 하는데… 이건 잘 얘기하셔서 스키마를 더 의미있게 만드시는게 좋을 것 같습니다 예를들면
Copy code
interface PetInfo

type DogInfo implements PetInfo
type CatInfo implements PetInfo
만 하셔도 쿼리는
Copy code
query Pets {
  pets(filter: { state: { ... } }) {
    id
    ...on DogInfo {
      # ...
    }
    ...on CatInfo {
      # ...
    }
  }
}
이런식으로 더 깔끔하게 갈라질겁니다.
Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
Client‐specified queries: Through its type system, a GraphQL server publishes the capabilities that its clients are allowed to consume. It is the client that is responsible for specifying exactly how it will consume those published capabilities. These queries are specified at field‐level granularity. In the majority of client‐server applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.
https://spec.graphql.org/June2018/#sec-Overview 이건 GraphQL 스펙에 명시되어있는 설계 원칙입니다.
백엔드팀에게 개선요청했으나, graphql은 필요한 데이터만 뽑아쓰고, 필터링 할 수 있기때문에 프론트에서 가공하는게 맞다.
이런 사고방식은 전반적으로 케이스 스터디 등 학습과정을 통해 개선할 필요가 있을거에요
z
와 링크 감사합니다. 저도 스키마 추상화 단위가 가공하기 어려운점이라고는 생각했는데, 테이블 구조상 변경하기는 어렵다고 합니다. (불가능한 것인지 어려운것인지는 판단하지 못했습니다) 팀과 같이 공유해서 ‘잘’ 활용해보도록 하겠습니다!
h
그리고 사실 서버 개발 편의를 위해 DB모델을 날것으로 노출한다고 쳐도 aggregate이 좀 필요해질 뿐이지 저렇게 API 사용하는데 조건이 과도하게 붙는 경우는 적을 것 같은데….
클라이언트에서 쓰기 불편한 GraphQL API는 존재의의가 많이 희미하다는걸 양측이 인지하는게 좋은 것 같아요. GraphQL 도입 초기에 백엔드 개발자가 그걸 인지하기 쉬운 방법은 스스로 클라이언트 프로토타이핑을 하거나 데이터 쿼리 요구사항을 처리해가면서 개밥먹기 하는거 일 듯 합니다. 로직이 있다면 스키마에 잘 드러나는게 좋고, 애초에 별 로직이 없다면 첨부터 자동생성해주는 솔루션을 도입하는게 여러모로 편하실겁니다. (ex. Hasura, Graphile)
z
와우 어떤 부분을 모르는걸까 너무 고민했는데 답변 너무 감사합니다. 똑똑하게 조율해보겠습니다 👍🙂👍
👏 1
👍 1
Open in Slack
PreviousNext
Powered by