Et godt skema er klientdrevet, nullable-som-standard ved kanterne og udvikleligt uden versioner. Det modellerer domænet i termer, klienter faktisk bruger, ikke dine databasetabeller.
Gør kun et felt non-null (!), når du altid kan returnere det. Overforbrug af ! er en fælde: hvis et non-null-felt fejler, sætter det hele sit parent-objekt til null og forvandler en lille fejl til et stort tomrum. Foretræk nullable for alt, der afhænger af en downstream-service.
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
}
isPublished).input-type og returner en payload-type — du kan tilføje felter senere uden at bryde signaturen.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL undgår /v2-URL'er. Du udvikler additivt: tilføj felter frit, og udfas gamle med @deprecated, mens klienter migrerer.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
At fjerne eller omdøbe et felt er den eneste ægte breaking change, så design, så du sjældent har brug for det. Undgå også at lække DB-formen (eksponer fullName, ikke first_name/last_name, hvis klienter vil have ét felt).
Disse valg er det, der adskiller et skema, der holder i årevis, fra et, klienter kæmper imod. Interviewere bruger dette til at måle API-designmodenhed — især afvejningen mellem nullability/fejl og den additive evolutionstankegang, som er unik for GraphQL.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér