GraphQL gjithmonë kthen HTTP 200 për një transport të suksesshëm; problemet raportohen në trupin e përgjigjes, jo në status code. Një përgjigje ka dy çelësa top-level: data dhe errors, dhe të dy mund të jenë të pranishëm njëkohësisht — kjo është partial data (të dhëna të pjesshme).
Nëse resolver-i i një fushe hedh exception, ajo fushë bëhet null, një hyrje shtohet te errors, por çdo fushë tjetër prapë zgjidhet. Klienti merr atë që pati sukses plus një përshkrim të asaj që dështoi.
{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // saktësisht cila fushë dështoi
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Fusha extensions.code mban një kod error-i të lexueshëm nga makina që klientët të degëzojnë sipas tij. Nëse një fushë që hedh exception e bën null vetëm veten apo ngjitet lart varet nga nullability: një fushë non-null (posts: [Post!]!) që jep error e bën null parent-in e saj më të afërt që është nullable.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// bashkëngjit një kod të qëndrueshëm ku klientët mund të degëzojnë; fshih detajet e brendshme
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Shumë ekipe i modelojnë gjithashtu error-et e pritura (validim, "email i zënë") si pjesë e schema-s përmes union/result types, duke rezervuar array-in errors për dështimet e papritura — duke e mbajtur të pastër tipizimin e happy-path.
Intervistuesit hetojnë nëse e dini se error-et rrojnë në trup me data të pjesshme, se kodet i përkasin extensions, dhe se nullability kontrollon sa larg ngjitet një error. Ngatërrimi i error-eve të GraphQL me HTTP status codes është një shenjë klasike që dikush ka përdorur vetëm REST.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro