Et godt schema er klientdrevet, nullable som standard i ytterkantene, og kan videreutvikles uten versjoner. Det modellerer domenet i termer klienter faktisk bruker, ikke databasetabellene dine.
Gjør et felt non-null (!) bare når du alltid kan returnere det. Overforbruk av ! er en felle: hvis et non-null felt feiler, nuller det hele parent-objektet sitt, og gjør en liten feil om til et stort tomrom. Foretrekk nullable for alt som avhenger av en nedstrøms tjeneste.
type User {
id: ID! # faktisk alltid til stede
email: String! # påkrevd i databasen din -> trygt som non-null
avatarUrl: String # kommer fra en ekstern tjeneste -> nullable, så feilen er isolert
}
isPublished).input-type og returner en payload-type — du kan legge til felt senere uten å bryte signaturen.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # rom til å vokse
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL unngår /v2-URL-er. Du videreutvikler additivt: legg til felt fritt, og pensjoner gamle med @deprecated mens klienter migrerer.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # fortsett å servere til klienter har flyttet seg vekk
}
Å fjerne eller gi nytt navn til et felt er den eneste ekte bruddendringen, så design slik at du sjelden trenger det. Unngå også å lekke databasens form (eksponer fullName, ikke first_name/last_name hvis klienter vil ha ett felt).
Disse valgene er det som skiller et schema som varer i årevis fra ett klienter sloss mot. Intervjuere bruker dette til å vurdere modenhet i API-design — spesielt avveiningen mellom nullability og feil, og tankesettet om additiv videreutvikling, som er unike for GraphQL.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner