Was sind Best Practices für das Design von GraphQL-Schemas?

Question

IT Interview Practice · Accepted Answer

Ein gutes Schema ist **client-getrieben, an den Rändern standardmäßig nullbar und ohne Versionen weiterentwickelbar**. Es modelliert die Domäne in Begriffen, die Clients tatsächlich nutzen, nicht in deinen Datenbanktabellen.

## Nullability

Mache ein Feld nur dann Non-Null (`!`), wenn du es *immer* zurückgeben kannst. Ein übermäßiger Einsatz von `!` ist eine Falle: Wirft ein Non-Null-Feld einen Fehler, nullt es sein gesamtes Parent-Objekt und macht aus einem kleinen Fehler eine große Leerstelle. Bevorzuge nullbar für alles, was von einem nachgelagerten Dienst abhängt.

```graphql
type User {
  id: ID!             # truly always present
  email: String!      # required in your DB -> safe as non-null
  avatarUrl: String   # comes from an external service -> nullable, so its failure is isolated
}
```

## Benennung & Inputs

- Verwende konsistente, aussagekräftige Namen; Booleans lesen sich als Prädikate (`isPublished`).
- Gib jeder Mutation einen einzigen **`input`**-Typ und lass sie einen **Payload**-Typ zurückgeben – so kannst du später Felder hinzufügen, ohne die Signatur zu brechen.

```graphql
input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! }  # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
```

## Weiterentwicklung ohne Versionierung

GraphQL vermeidet `/v2`-URLs. Du entwickelst **additiv** weiter: Füge Felder frei hinzu und ziehe alte mit `@deprecated` außer Dienst, während Clients migrieren.

```graphql
type User {
  fullName: String!
  name: String! @deprecated(reason: "Use fullName")   # keep serving until clients move off
}
```

Ein Feld zu entfernen oder umzubenennen ist die einzige echte Breaking Change, deshalb solltest du so designen, dass du es selten brauchst. Vermeide außerdem, die DB-Struktur durchsickern zu lassen (exponiere `fullName`, nicht `first_name`/`last_name`, wenn Clients ein einziges Feld wollen).

## Warum es wichtig ist

Diese Entscheidungen trennen ein Schema, das jahrelang hält, von einem, gegen das Clients ankämpfen. Interviewer nutzen das, um die **Reife im API-Design** einzuschätzen – besonders den Trade-off zwischen Nullability und Fehlern und die Denkweise der additiven Weiterentwicklung, die einzigartig für GraphQL ist.

Nullability

Benennung & Inputs

Weiterentwicklung ohne Versionierung

Warum es wichtig ist

Ähnliche Fragen