Warum Sie Hilfsmethoden in GraphQL-Resolvern vermeiden sollten

GraphQL hat die Art und Weise, wie wir Daten abrufen und formen, revolutioniert und eine saubere Abstraktionsschicht zwischen Clients und Servern bereitgestellt. Eine seiner Kernfunktionen, Resolver, ermöglicht es uns zu definieren, wie jedes Feld in unserem Schema seine Daten erhält. In einigen Fällen schmälern Entwickler möglicherweise unbeabsichtigt die Vorteile von GraphQL, indem sie sich auf Hilfsmethoden in Resolvern verlassen. Diese Vorgehensweise macht nicht nur den Zweck des GraphQL-Designs zunichte, sondern führt auch zu unnötiger Komplexität und potenziellen Fehlern.

Lassen Sie uns untersuchen, warum dies problematisch ist und wie man es besser machen kann.

Die Macht der Resolver

In GraphQL werden Resolver für jede Instanz eines Typs aufgerufen, unabhängig davon, wo dieser Typ in Ihrem Schema erscheint. Diese Abstraktion stellt sicher, dass die Logik zur Datenauflösung durchgängig konsistent bleibt. Zum Beispiel:

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!
}

Hier wird der Benutzertyp an zwei Stellen verwendet: direkt in der Abfrage zum Abrufen von Benutzern und verschachtelt innerhalb des Projekttyps als Eigentümer. Dank des Resolver-Systems von GraphQL können wir einen einzelnen Benutzer-Resolver definieren, der die Auflösung von Benutzerfeldern verwaltet und so ein konsistentes Verhalten überall dort gewährleistet, wo Benutzer angezeigt werden.

Das Problem mit Dienstprogrammen

Wenn Sie Hilfsmethoden zur Datenformung außerhalb Ihrer Resolver einführen, durchbrechen Sie diese Abstraktion. Betrachten Sie dieses Beispiel:

// 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
    },
  },
};

Auf den ersten Blick scheint das in Ordnung zu sein. Aber hier ist der Grund, warum es problematisch ist:

1. Duplizierte Logik

Sie müssen „mapToUser“ in jedem Resolver aufrufen, in dem ein Benutzertyp angezeigt wird. Wenn Sie vergessen, es aufzurufen, oder es falsch aufrufen, kann dies zu inkonsistentem Verhalten in Ihrer gesamten API führen.

2. Abstraktion brechen

Das Resolver-System von GraphQL ist darauf ausgelegt, die Auflösung jedes Typs zu zentralisieren. Durch die Verwendung einer Dienstprogrammmethode umgehen Sie diese Funktion und machen Ihren Code weniger intuitiv.

3. Verlust der Flexibilität

Wenn Sie jemals ändern müssen, wie ein Benutzertyp aufgelöst wird (z. B. neue Felder hinzufügen oder Fehler behandeln), müssen Sie jede Stelle aufspüren, an der „mapToUser“ aufgerufen wird, anstatt einen einzelnen Resolver zu aktualisieren.

Der bessere Ansatz: Typ-Resolver nutzen

Anstatt Dienstprogrammmethoden zu verwenden, definieren Sie Resolver für Ihre GraphQL-Typen. So können Sie das obige Beispiel umschreiben:

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!
}

Warum das besser ist

1. Konsistenz: Der Benutzer-Resolver stellt sicher, dass alle Benutzerinstanzen auf die gleiche Weise aufgelöst werden, unabhängig davon, wo sie im Schema erscheinen.
2. Zentralisierte Logik: Änderungen an der Lösung eines Benutzers müssen nur an einer Stelle vorgenommen werden.
3. Die Stärken von GraphQL nutzen: Durch die Nutzung des Resolver-Systems stimmen Sie mit den zentralen Designprinzipien von GraphQL überein und nutzen dessen volles Potenzial.

Abschluss

Die Verwendung von Hilfsmethoden in Ihren Resolvern mag wie eine Abkürzung erscheinen, untergräbt jedoch letztendlich die Leistungsfähigkeit und Eleganz von GraphQL. Durch die Definition von Resolvern für Ihre Typen können Sie eine saubere, konsistente und skalierbare API aufrechterhalten. Hören Sie also auf, Dienstprogramme in Ihren Resolvern zu verwenden, und nutzen Sie die Abstraktion, die GraphQL bietet – Ihr zukünftiges Ich wird es Ihnen danken!

Das obige ist der detaillierte Inhalt vonWarum Sie Hilfsmethoden in GraphQL-Resolvern vermeiden sollten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!