Dobré schéma je řízené klientem, nullable ve výchozím stavu na okrajích a rozvíjitelné bez verzí. Modeluje doménu termíny, které klienti skutečně používají, ne vaše databázové tabulky.
Pole označte jako non-null (!) jen tehdy, když jej dokážete vždy vrátit. Nadužívání ! je past: pokud non-null pole selže, vynuluje celý svůj rodičovský objekt a z malého selhání se stane velké prázdné místo. Cokoli, co závisí na navazující službě, raději nechte nullable.
type User {
id: ID! # opravdu vždy přítomné
email: String! # ve vaší DB povinné -> bezpečně non-null
avatarUrl: String # pochází z externí služby -> nullable, takže jeho selhání je izolované
}
isPublished).input a vracejte typ payload — pole můžete přidat později, aniž byste porušili signaturu.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # prostor pro růst
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL se vyhýbá URL typu /v2. Rozvíjíte aditivně: pole přidávejte volně a stará vyřazujte pomocí @deprecated, zatímco klienti migrují.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # obsluhuj, dokud klienti nepřejdou
}
Odstranění nebo přejmenování pole je jediná skutečná breaking change, takže navrhujte tak, abyste to potřebovali jen zřídka. Také se vyhněte prosakování tvaru DB (vystavte fullName, ne first_name/last_name, pokud klienti chtějí jedno pole).
Tato rozhodnutí odlišují schéma, které vydrží roky, od toho, se kterým klienti bojují. Tazatelé tím měří zralost návrhu API — zejména kompromis nullability/chyby a myšlení aditivního rozvoje, které jsou pro GraphQL jedinečné.
Knihovna IT otázek k pohovoru s podrobnými odpověďmi — od Junior po Senior.
Přispět