GraphQL リゾルバーでユーティリティメソッドを避けるべき理由-jsチュートリアル-php.cn

GraphQL リゾルバーでユーティリティメソッドを避けるべき理由

Susan Sarandon

リリース： 2025-01-05 03:40:39

オリジナル

773 人が閲覧しました

Why You Should Avoid Utility Methods in GraphQL Resolvers

GraphQL は、データのフェッチと整形方法に革命をもたらし、クライアントとサーバーの間にクリーンな抽象化レイヤーを提供します。その中心機能の 1 つであるリゾルバーを使用すると、スキーマ内の各フィールドがデータを取得する方法を定義できます。場合によっては、開発者がリゾルバーのユーティリティメソッドに依存することで、意図せずに 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!
}

ログイン後にコピー

ここでは、ユーザータイプが 2 つの場所で使用されています。ユーザーを取得するためにクエリ内で直接使用され、所有者としてプロジェクトタイプ内にネストされています。 GraphQL のリゾルバーシステムのおかげで、ユーザーフィールドの解決方法を処理する単一のユーザーリゾルバーを定義でき、ユーザーが表示される場所で一貫した動作を保証できます。

ユーティリティの問題

リゾルバーの外部でデータを整形するユーティリティメソッドを導入すると、この抽象化が破壊されます。次の例を考えてみましょう:

// 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. 重複したロジック

User タイプが表示されるすべてのリゾルバーで、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 か所でのみ行う必要があります。
GraphQL の強みを活用する: リゾルバーシステムを採用することで、GraphQL の中核となる設計原則と一致し、その可能性を最大限に活用することができます。

結論

リゾルバーでユーティリティメソッドを使用するのは近道のように思えるかもしれませんが、最終的には GraphQL のパワーと優雅さを損なうことになります。型のリゾルバーを定義することで、クリーンで一貫性があり、スケーラブルな API を維持できます。したがって、リゾルバーでのユーティリティの使用をやめ、GraphQL が提供する抽象化を受け入れてください。将来のあなたはあなたに感謝するでしょう!

以上がGraphQL リゾルバーでユーティリティメソッドを避けるべき理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。