เลือกโดยพิจารณาจาก ใครเป็นผู้ใช้ API และความต้องการข้อมูลของพวกเขาหลากหลายเพียงใด — ไม่ใช่ตามกระแส GraphQL ชนะเมื่อมี client หลากหลายจำนวนมากที่ต้องการจัดรูปข้อมูลของตนเอง ส่วน REST ชนะเมื่อ request มีรูปแบบสม่ำเสมอ cache ได้ และเรียบง่าย
เลือกโดยพิจารณาจาก ใครเป็นผู้ใช้ API และความต้องการข้อมูลของพวกเขาหลากหลายเพียงใด — ไม่ใช่ตามกระแส GraphQL ชนะเมื่อมี client หลากหลายจำนวนมากที่ต้องการจัดรูปข้อมูลของตนเอง ส่วน REST ชนะเมื่อ request มีรูปแบบสม่ำเสมอ cache ได้ และเรียบง่าย
user -> posts -> comments) แทนที่จะต้องเรียก REST N รอบGET ของ REST cache ได้ง่ายในทุกชั้น ส่วน GraphQL ต้องใช้ persisted query จึงจะเข้าใกล้ได้| ประเด็น | GraphQL | REST |
|---|---|---|
| Over/under-fetching | แก้ได้ด้วยการออกแบบ | ปัญหาที่พบบ่อย |
| HTTP/CDN caching | ยาก (ต้องลงแรง) | มีมาในตัวและง่าย |
| การควบคุม query-cost/DoS | ต้องเพิ่มเอง | มีขอบเขตตามธรรมชาติ |
| ความยืดหยุ่นของ client | สูง | ต่ำ |
| ความซับซ้อนฝั่ง server | สูงกว่า | ต่ำกว่า |
ทั้งสองยังไม่ได้แยกขาดจากกัน — หลายระบบเปิด REST สำหรับ endpoint สาธารณะ/ที่ cache ได้ และเปิด GraphQL สำหรับ client ภายในที่ต้องการข้อมูลเข้มข้น
ผู้สัมภาษณ์ระดับ senior กำลังทดสอบ วิจารณญาณ ไม่ใช่ความภักดี คำตอบที่ดีจะระบุแกนต่าง ๆ — ความหลากหลายของ client, ความต้องการด้าน caching, วุฒิภาวะของทีม, พื้นผิวการโจมตี DoS — และยอมรับต้นทุนที่แท้จริงของ GraphQL (การ caching และการควบคุม query-cost) แทนที่จะขายมันว่าดีกว่าในทุกกรณี
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค