Hyvä schema on client-vetoinen, oletuksena nullable reunoillaan ja kehitettävissä ilman versioita. Se mallintaa domainin niillä termeillä, joita clientit oikeasti käyttävät, ei tietokantatauluillasi.
Tee kentästä non-null (!) vain silloin, kun voit aina palauttaa sen. !:n liikakäyttö on ansa: jos non-null-kenttä virheytyy, se nulaa koko parent-objektinsa, muuttaen pienen vian isoksi tyhjäksi kohdaksi. Suosi nullablea kaikelle, mikä riippuu downstream-palvelusta.
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-tyyppi ja palauta payload-tyyppi — voit lisätä kenttiä myöhemmin rikkomatta allekirjoitusta.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL välttää /v2-URL-osoitteet. Kehität additiivisesti: lisää kenttiä vapaasti ja poista vanhoja @deprecatedilla clientien migratoituessa.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
Kentän poistaminen tai uudelleennimeäminen on ainoa aito rikkova muutos, joten suunnittele niin, että tarvitset sitä harvoin. Vältä myös DB-muodon vuotamista (paljasta fullName, älä first_name/last_name, jos clientit haluavat yhden kentän).
Nämä valinnat erottavat vuosia kestävän scheman siitä, jota vastaan clientit taistelevat. Haastattelijat mittaavat tällä API-suunnittelun kypsyyttä — erityisesti nullabilityn/virheiden kompromissia ja additiivisen kehityksen ajattelutapaa, jotka ovat GraphQL:lle ainutlaatuisia.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita