Một schema tốt thì hướng client, mặc định nullable ở các rìa, và tiến hóa được mà không cần version. Nó mô hình hóa domain theo cách client thực sự dùng, không phải theo bảng database của bạn.
Chỉ đặt một field là non-null (!) khi bạn luôn luôn có thể trả về nó. Lạm dụng ! là một cái bẫy: nếu một field non-null lỗi, nó sẽ null cả object parent, biến một sự cố nhỏ thành một khoảng trống lớn. Ưu tiên nullable cho bất cứ thứ gì phụ thuộc vào một service downstream.
type User {
id: ID! # thực sự luôn có mặt
email: String! # bắt buộc trong DB -> an toàn để non-null
avatarUrl: String # đến từ service ngoài -> nullable, để sự cố của nó được cô lập
}
isPublished).input duy nhất và trả về một type payload — sau này bạn có thể thêm field mà không phá vỡ chữ ký.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # chừa chỗ để mở rộng
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL tránh URL kiểu /v2. Bạn tiến hóa theo kiểu cộng thêm (additive): thêm field thoải mái, và loại field cũ bằng @deprecated trong khi client di cư.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # vẫn phục vụ tới khi client chuyển đi
}
Xóa hoặc đổi tên một field là thay đổi phá vỡ (breaking) thực sự duy nhất, nên hãy thiết kế sao cho hiếm khi cần làm vậy. Cũng tránh lộ hình dạng DB (phơi bày fullName, không phải first_name/last_name nếu client muốn một field).
Những lựa chọn này phân biệt một schema trụ được nhiều năm với một schema mà client phải vật lộn để dùng. Người phỏng vấn dùng câu này để đo độ chín trong thiết kế API — nhất là đánh đổi nullability/lỗi và tư duy tiến hóa cộng thêm, vốn là đặc trưng riêng của GraphQL.
Thư viện câu hỏi phỏng vấn IT với đáp án chi tiết — từ Junior đến Senior.
Ủng hộ