Vilka är de bästa metoderna för GraphQL-schemadesign?

Question

IT Interview Practice · Accepted Answer

Ett bra schema är **klientdrivet, nullbart som standard i ytterkanterna och möjligt att vidareutveckla utan versioner**. Det modellerar domänen i termer som klienter faktiskt använder, inte dina databastabeller.

## Nullability

Gör ett fält non-null (`!`) endast när du *alltid* kan returnera det. Att överanvända `!` är en fälla: om ett non-null-fält ger fel nollar det hela sitt föräldraobjekt och förvandlar ett litet misslyckande till en stor tomhet. Föredra nullbart för allt som är beroende av en nedströmstjänst.

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

## Namngivning och inputs

- Använd konsekventa, beskrivande namn; booleaner läses som predikat (`isPublished`).
- Ge varje mutation en enda **`input`**-typ och returnera en **payload**-typ — du kan lägga till fält senare utan att bryta signaturen.

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

## Vidareutveckling utan versionering

GraphQL undviker `/v2`-URL:er. Du utvecklar **additivt**: lägg till fält fritt, och avveckla gamla med `@deprecated` medan klienterna migrerar.

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

Att ta bort eller byta namn på ett fält är den enda verkligt brytande ändringen, så designa så att du sällan behöver. Undvik även att läcka databasstruktur (exponera `fullName`, inte `first_name`/`last_name` om klienterna vill ha ett enda fält).

## Varför det är viktigt

Dessa val är vad som skiljer ett schema som håller i åratal från ett som klienterna kämpar emot. Intervjuare använder detta för att bedöma **mognad i API-design** — särskilt avvägningen mellan nullability och fel samt tankesättet med additiv vidareutveckling, som är unika för GraphQL.

Nullability

Namngivning och inputs

Vidareutveckling utan versionering

Varför det är viktigt

Relaterade frågor