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

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. 一貫性: ユーザー リゾルバーは、スキーマ内のどこに存在するかに関係なく、すべてのユーザー インスタンスが同じ方法で解決されることを保証します。
2. 集中ロジック: ユーザーの解決方法の変更は 1 か所でのみ行う必要があります。
3. GraphQL の強みを活用する: リゾルバー システムを採用することで、GraphQL の中核となる設計原則と一致し、その可能性を最大限に活用することができます。

結論

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

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