Dobra shema je vođena klijentom, prema zadanom nullable na rubovima i može se razvijati bez verzija. Ona modelira domenu u terminima koje klijenti stvarno koriste, a ne vaše tablice baze podataka.
Učinite polje non-null (!) samo kada ga uvijek možete vratiti. Pretjerana uporaba ! je zamka: ako non-null polje zakaže, poništava cijeli svoj nadređeni objekt, pretvarajući mali kvar u veliku prazninu. Za sve što ovisi o downstream servisu radije koristite nullable.
type User {
id: ID! # doista uvijek prisutno
email: String! # obavezno u vašoj bazi -> sigurno kao non-null
avatarUrl: String # dolazi iz vanjskog servisa -> nullable, pa je njegov kvar izoliran
}
isPublished).input tip i vraćajte payload tip — polja možete dodati kasnije bez razbijanja potpisa.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # prostor za rast
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL izbjegava /v2 URL-ove. Razvijate se aditivno: slobodno dodajte polja i povlačite stara s @deprecated dok klijenti migriraju.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # nastavi posluživati dok klijenti ne prijeđu
}
Uklanjanje ili preimenovanje polja jedina je istinska promjena koja lomi kompatibilnost, pa dizajnirajte tako da vam to rijetko treba. Također izbjegavajte curenje oblika baze (izložite fullName, a ne first_name/last_name ako klijenti žele jedno polje).
Te odluke razdvajaju shemu koja traje godinama od one protiv koje se klijenti bore. Ispitivači ovim procjenjuju zrelost u dizajnu API-ja — osobito kompromis nullabilnost/pogreške i način razmišljanja o aditivnoj evoluciji, koji su svojstveni GraphQL-u.
Knjižnica IT pitanja za razgovore za posao s detaljnim odgovorima — od Juniora do Seniora.
Doniraj