schema ที่ดีคือ ขับเคลื่อนโดย client, เป็น nullable โดยปริยายที่ขอบ, และวิวัฒน์ได้โดยไม่ต้องมีเวอร์ชัน มันจำลอง domain ในแบบที่ client ใช้งานจริง ไม่ใช่ตาม table ของฐานข้อมูลคุณ
กำหนดให้ field เป็น non-null (!) เฉพาะเมื่อคุณ สามารถส่งคืนได้เสมอ เท่านั้น การใช้ ! มากเกินไปเป็นกับดัก: หาก non-null field เกิด error มันจะทำให้ object parent ทั้งก้อนเป็น null เปลี่ยนความล้มเหลวเล็ก ๆ ให้กลายเป็นช่องว่างขนาดใหญ่ ควรเลือก nullable สำหรับสิ่งใดก็ตามที่พึ่งพา downstream service
type User {
id: ID! # truly always present
email: String! # required in your DB -> safe as non-null
avatarUrl: String # comes from an external service -> nullable, so its failure is isolated
}
isPublished)input เพียงตัวเดียว และส่งคืน type payload — คุณจะเพิ่ม field ภายหลังได้โดยไม่ทำให้ signature พังinput CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL หลีกเลี่ยง URL แบบ /v2 คุณวิวัฒน์แบบ เพิ่มเข้าไป (additive): เพิ่ม field ได้อย่างอิสระ และปลดระวางของเก่าด้วย @deprecated ในระหว่างที่ client ค่อย ๆ ย้าย
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
การลบหรือเปลี่ยนชื่อ field คือ breaking change ที่แท้จริงเพียงอย่างเดียว จงออกแบบให้คุณแทบไม่ต้องทำเช่นนั้น อีกทั้งควรหลีกเลี่ยงการเผยรูปทรงของ DB (เปิดเผย fullName ไม่ใช่ first_name/last_name หาก client ต้องการ field เดียว)
ตัวเลือกเหล่านี้คือสิ่งที่แยก schema ที่ใช้งานได้ยาวนานหลายปีออกจาก schema ที่ client ต้องต่อสู้ด้วย ผู้สัมภาษณ์ใช้สิ่งนี้ประเมิน วุฒิภาวะในการออกแบบ API — โดยเฉพาะ trade-off ระหว่าง nullability กับ error และแนวคิดการวิวัฒน์แบบเพิ่มเข้าไป ซึ่งเป็นเอกลักษณ์ของ GraphQL
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค