Un buon schema è guidato dal client, nullable per default ai bordi ed evolvibile senza versioni. Modella il dominio nei termini che i client usano davvero, non le tabelle del tuo database.
Rendi un campo non-null (!) solo quando puoi sempre restituirlo. Abusare del ! è una trappola: se un campo non-null va in errore, annulla l'intero oggetto parent, trasformando un piccolo fallimento in un grande vuoto. Preferisci nullable per qualsiasi cosa dipenda da un servizio downstream.
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 e restituisci un tipo payload — potrai aggiungere campi in seguito senza rompere la firma.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL evita gli URL /v2. Si evolve in modo additivo: aggiungi campi liberamente e ritira quelli vecchi con @deprecated mentre i client migrano.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
Rimuovere o rinominare un campo è l'unico vero cambiamento che rompe la compatibilità, quindi progetta in modo da doverlo fare raramente. Evita anche di far trapelare la forma del DB (esponi fullName, non first_name/last_name se i client vogliono un unico campo).
Queste scelte sono ciò che distingue uno schema che dura anni da uno contro cui i client combattono. Gli intervistatori le usano per valutare la maturità nella progettazione delle API — in particolare il compromesso nullabilità/errori e la mentalità dell'evoluzione additiva, che sono peculiari di GraphQL.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona