Dobra shema je vodena od odjemalca, privzeto ničljiva na robovih in razvojna brez verzij. Domeno modelira v izrazih, ki jih odjemalci dejansko uporabljajo, ne po tvojih tabelah v bazi.
Polje naredi non-null (!) samo takrat, ko ga lahko vrneš. Prekomerna uporaba je past: če non-null polje vrže napako, na postavi svoj celoten nadrejeni objekt in majhno odpoved spremeni v veliko praznino. Za karkoli, kar je odvisno od storitve nižje v verigi, raje uporabi ničljivo polje.
!nulltype 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 in vrni tip payload — kasneje lahko dodaš polja, ne da bi pokvaril podpis.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL se izogne URL-jem /v2. Razvijaš aditivno: polja dodajaš prosto, stara pa upokojiš z @deprecated, medtem ko odjemalci migrirajo.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
Odstranitev ali preimenovanje polja je edina resnična rušilna sprememba, zato načrtuj tako, da jo redko potrebuješ. Prav tako se izogni razkrivanju oblike baze (izpostavi fullName, ne first_name/last_name, če odjemalci želijo eno polje).
te odločitve so tisto, kar loči shemo, ki zdrži leta, od tiste, proti kateri se odjemalci borijo. Izpraševalci to uporabijo za oceno zrelosti načrtovanja API-jev — zlasti kompromisa ničelnost/napake in miselnosti aditivnega razvoja, ki sta značilna za GraphQL.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj