GraphQL સફળ transport માટે હંમેશા HTTP 200 પરત કરે છે; સમસ્યાઓ status code માં નહીં પણ response body માં જણાવાય છે. Response ને બે top-level keys હોય છે: data અને errors, અને બંને એકસાથે હાજર હોઈ શકે — એ છે partial data.
જો કોઈ એક field ના resolver માં throw થાય, તો તે field બની જાય છે, માં એક entry ઉમેરાય છે, પણ બાકીના દરેક field હજુ resolve થાય છે. Client ને જે સફળ થયું તે ઉપરાંત જે નિષ્ફળ ગયું તેનું વર્ણન મળે છે.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
extensions.code field એક machine-readable error code વહન કરે છે જેથી clients તેના પર branch કરી શકે. Throw થયેલ field ફક્ત પોતાને null કરે કે ઉપર bubble થાય તે nullability પર આધાર રાખે છે: non-null field (posts: [Post!]!) જે error કરે તે તેની બદલે તેના નજીકના nullable parent ને null કરે છે.
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" },
});
}
// ...
},
},
};
ઘણી teams અપેક્ષિત errors (validation, "email taken") ને union/result types દ્વારા schema ના ભાગ તરીકે model પણ કરે છે, અને errors array ને અનપેક્ષિત failures માટે અનામત રાખે છે — જેથી happy-path typing સ્વચ્છ રહે.
Interviewers તપાસે છે કે તમે જાણો છો કે errors partial data સાથે body માં રહે છે, codes extensions માં હોય છે, અને nullability error કેટલે દૂર bubble થાય તે નિયંત્રિત કરે છે. GraphQL errors ને HTTP status codes સાથે ગૂંચવવું એ ક્લાસિક સંકેત છે કે કોઈએ ફક્ત REST વાપર્યું છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો