This message was deleted.
# 질문
s
This message was deleted.
👀 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