GraphQL gibt für einen erfolgreichen Transport immer HTTP 200 zurück; Probleme werden im Response-Body gemeldet, nicht im Statuscode. Eine Antwort hat zwei Schlüssel auf oberster Ebene: data und errors, und beide können gleichzeitig vorhanden sein – das sind partielle Daten.
Wenn der Resolver eines Feldes eine Exception wirft, wird dieses Feld null, ein Eintrag wird zu errors hinzugefügt, aber jedes andere Feld wird trotzdem aufgelöst. Der Client erhält, was erfolgreich war, plus eine Beschreibung dessen, was fehlgeschlagen ist.
{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Das Feld extensions.code trägt einen maschinenlesbaren Fehlercode, auf den Clients verzweigen können. Ob ein geworfenes Feld nur sich selbst nullt oder nach oben durchschlägt, hängt von der Nullability ab: Ein Non-Null-Feld (posts: [Post!]!), das einen Fehler wirft, nullt stattdessen seinen nächstgelegenen nullbaren Parent.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// attach a stable code clients can switch on; hide internal details
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Viele Teams modellieren auch erwartete Fehler (Validierung, „E-Mail bereits vergeben“) als Teil des Schemas über Union-/Result-Typen und reservieren das errors-Array für unerwartete Fehler – so bleibt die Typisierung des Happy Path sauber.
Interviewer prüfen, ob du weißt, dass Fehler mit partiellen data im Body liegen, dass Codes in extensions gehören und dass die Nullability steuert, wie weit ein Fehler nach oben durchschlägt. GraphQL-Fehler mit HTTP-Statuscodes zu verwechseln, ist ein klassisches Anzeichen dafür, dass jemand nur REST verwendet hat.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden