GraphQL selalu mengembalikan HTTP 200 untuk transport yang berhasil; masalah dilaporkan di body response, bukan di status code. Sebuah response punya dua key top-level: data dan errors, dan keduanya bisa hadir sekaligus — itulah partial data.
Jika resolver satu field melempar error, field itu menjadi , sebuah entry ditambahkan ke , tetapi setiap field lain tetap di-resolve. Client mendapat apa yang berhasil ditambah deskripsi apa yang gagal.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Field extensions.code membawa kode error yang bisa dibaca mesin sehingga client bisa bercabang berdasarkan itu. Apakah field yang melempar error hanya menjadikan dirinya sendiri null atau merambat ke atas (bubble up) bergantung pada nullability: sebuah field non-null (posts: [Post!]!) yang error justru menjadikan parent nullable terdekatnya 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" },
});
}
// ...
},
},
};
Banyak tim juga memodelkan error yang diharapkan (expected) (validasi, "email sudah dipakai") sebagai bagian dari schema lewat union/result type, dan mencadangkan array errors untuk kegagalan yang tak terduga (unexpected) — sehingga typing jalur bahagia (happy path) tetap bersih.
Interviewer menyelidiki apakah Anda tahu bahwa error berada di body bersama data parsial, bahwa kode termasuk di extensions, dan bahwa nullability mengontrol seberapa jauh sebuah error merambat. Mengacaukan GraphQL error dengan HTTP status code adalah tanda klasik bahwa seseorang hanya pernah memakai REST.
Perpustakaan pertanyaan wawancara IT dengan jawaban mendetail — dari Junior hingga Senior.
Donasi