GraphQL 해석기에서 유틸리티 메서드를 피해야 하는 이유

GraphQL은 데이터를 가져오고 형성하는 방식을 혁신하여 클라이언트와 서버 사이에 깔끔한 추상화 계층을 제공합니다. 핵심 기능 중 하나인 해석기를 사용하면 스키마의 각 필드가 데이터를 얻는 방법을 정의할 수 있습니다. 어떤 경우에는 개발자가 해석기의 유틸리티 메서드에 의존하여 의도치 않게 GraphQL의 이점을 감소시킬 수 있습니다. 이러한 관행은 GraphQL 디자인의 목적을 무너뜨릴 뿐만 아니라 불필요한 복잡성과 잠재적인 버그를 야기합니다.

이것이 문제가 되는 이유와 개선 방법에 대해 자세히 알아보겠습니다.

리졸버의 힘

GraphQL에서는 해당 유형이 스키마에 나타나는 위치에 관계없이 유형의 모든 인스턴스에 대해 해석기가 호출됩니다. 이러한 추상화는 데이터 해결 논리가 전반적으로 일관되게 유지되도록 보장합니다. 예:

schema {
  query: Query
}

type Query {
  project(id: ID!): Project
  user(id: ID!): User
}

type Project {
  id: ID!
  name: String!
  owner: User!
}

type User {
  id: ID!
  name: String!
  email: String!
}

여기서 사용자 유형은 사용자를 가져오기 위한 쿼리에서 직접 사용되는 것과 소유자로서 프로젝트 유형 내에 중첩되는 두 가지 위치에서 사용됩니다. GraphQL의 해석기 시스템 덕분에 User 필드가 해석되는 방식을 처리하는 단일 User 해석기를 정의하여 User가 나타나는 모든 곳에서 일관된 동작을 보장할 수 있습니다.

유틸리티 문제

리졸버 외부에서 데이터를 형성하기 위해 유틸리티 메서드를 도입하면 이러한 추상화가 깨집니다. 다음 예를 고려해보세요:

// utils.ts
function mapToUser(userData: DataSourceUser) {
  return {
    id: userData.id,
    name: userData.full_name,
    email: userData.contact_email,
  };
}

// resolvers.ts
const resolvers: Resolvers<Context> = {
  Query: {
    project: async (_, { id }, { dataSources }) => {
      const project = await dataSources.projectAPI.getProject(id);
      return {
        ...project,
        owner: mapToUser(project.owner), // Utility method called here
      };
    },
    user: async (_, { id }, { dataSources }) => {
      const user = await dataSources.userAPI.getUser(id);
      return mapToUser(user); // Utility method called here
    },
  },
};

얼핏 보면 괜찮아 보일 수도 있습니다. 하지만 문제가 되는 이유는 다음과 같습니다.

1. 중복된 ​​논리

사용자 유형이 나타나는 모든 확인자에서는 mapToUser를 호출해야 합니다. 호출하는 것을 잊어버리거나 잘못 호출하면 API 전체에서 일관되지 않은 동작이 발생할 수 있습니다.

2. 추상화를 깨다

GraphQL의 리졸버 시스템은 각 유형이 해결되는 방식을 중앙 집중화하도록 설계되었습니다. 유틸리티 방법을 사용하면 이 기능을 회피하고 코드의 직관적이게 됩니다.

3. 유연성 상실

사용자 유형이 확인되는 방식을 수정해야 하는 경우(예: 새 필드 추가 또는 오류 처리) 단일 확인자를 업데이트하는 대신 mapToUser가 호출되는 모든 위치를 찾아야 합니다.

더 나은 접근 방식: 유형 분석기 활용

유틸리티 메서드를 사용하는 대신 GraphQL 유형에 대한 해석기를 정의하세요. 위의 예를 다시 작성하는 방법은 다음과 같습니다.

schema {
  query: Query
}

type Query {
  project(id: ID!): Project
  user(id: ID!): User
}

type Project {
  id: ID!
  name: String!
  owner: User!
}

type User {
  id: ID!
  name: String!
  email: String!
}

이것이 더 나은 이유

1. 일관성: User 해석기는 모든 User 인스턴스가 스키마의 어디에 나타나든 동일한 방식으로 해석되도록 보장합니다.
2. 중앙 집중식 논리: 사용자 해결 방법을 한 곳에서만 변경하면 됩니다.
3. GraphQL의 장점 활용: 리졸버 시스템을 수용하면 GraphQL의 핵심 설계 원칙에 부합하고 잠재력을 최대한 활용할 수 있습니다.

결론

리졸버에서 유틸리티 메서드를 사용하는 것은 지름길처럼 보일 수 있지만 궁극적으로 GraphQL의 성능과 우아함을 약화시킵니다. 유형에 대한 해석기를 정의하면 깔끔하고 일관되며 확장 가능한 API를 유지할 수 있습니다. 따라서 리졸버에서 유틸리티 사용을 중단하고 GraphQL이 제공하는 추상화를 수용하세요. 미래의 여러분도 감사할 것입니다!

위 내용은 GraphQL 해석기에서 유틸리티 메서드를 피해야 하는 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!