กว่า 6 ปีเต็มที่ใช้มา ทำไมผมถึงไม่แนะนำ GraphQL อีกต่อไป

ผมไปเจอบทความ "Why, after 6 years, I’m over GraphQL" ของคุณ Matt Bessy มา ซึ่งเขียนเอาไว้ได้น่าสนใจเกี่ยวกับ GraphQL

ก่อนที่จะไปดูว่าปัญหาหลักที่แกเจอนั้นคืออะไร และทำไมเลือกที่จะพอแล้วกับ GraphQL หลังจากที่ใช้งานเต็ม ๆ กว่า 6 ปี ตั้งแต่ปี 2018-2024 มา recap คร่าว ๆ กันก่อนเนอะว่า GraphQL คืออะไร

GraphQL คืออะไร?

GraphQL เป็นโปรโตคอลหรือภาษาสำหรับการรับส่งข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ พัฒนาโดย Facebook ในปี 2012 และเปิดตัวสู่สาธารณะในปี 2015 ซึ่ง GraphQL ช่วยให้ client สามารถกำหนดโครงสร้างของข้อมูลที่ต้องการได้อย่างแม่นยำ โดยไม่ต้องพึ่งพาหลาย end-points เหมือนกับ REST (คือไอ้เจ้า GraphQL เนี่ยะฝั่ง client สามารถ request ข้อมูลเฉพาะที่ต้องการใน request เดียว ไม่ต้องใช้หลาย end-points เหมือน REST) ซึ่งช่วยลดปัญหาการดึงข้อมูลเกินจำเป็น (over-fetching) และการดึงข้อมูลไม่เพียงพอ (under-fetching)
ทีนี้มาดูปัญหาที่แกเจอครับ

โดยเหมือนจะเป็นปัญหาด้านความปลอดภัยและประสิทธิภาพ ซึ่งเหมือนเป็นการเพิ่มความซับซ้อนให้กับ codebase ของแกอย่างมาก ในขณะที่การพัฒนา API แบบ REST นั้นมักจะเรียบง่ายกว่ามากสำหรับ backend dev ที่จะนำไปใช้และทำความเข้าใจ

ปัญหาหลักของ GraphQL ที่คุณ Matt พบ

✅ 1. Surface Attack ที่กว้างขึ้น - การเปิดให้ client สามารถส่งคำถาม (query) ได้อย่างอิสระเพิ่มโอกาสในการถูกโจมตี
✅ 2. การตรวจสอบสิทธิ์ (Authorization) - ต้องมีการตรวจสอบสิทธิ์ในทุกฟิลด์ ซึ่งเป็นงานที่ยุ่งยากกว่าใน REST
✅ 3. การจำกัดอัตรา (Rate Limiting) - ไม่มีการจำกัดขนาดของคำถามที่ส่งมา ทำให้สามารถส่งคำถามที่ซับซ้อนเพื่อโจมตีเซิร์ฟเวอร์ได้
✅ 4. การแยกวิเคราะห์คำถาม (Query Parsing) - คำถามที่ไม่ถูกต้องอาจทำให้เซิร์ฟเวอร์ล้มเหลวได้
✅ 5. ประสิทธิภาพ (Performance) - ปัญหาการดึงข้อมูลหลายครั้ง (N+1 problem) และการตรวจสอบสิทธิ์ (Authorization) ที่ซับซ้อนทำให้ระบบทำงานช้าลง
✅ 6. ความซับซ้อน (Complexity) - การแก้ปัญหาต่าง ๆ เหล่านี้เพิ่มความซับซ้อนให้กับโค้ดเบส ทำให้ยากต่อการพัฒนาและบำรุงรักษา

อย่างไรก็ตาม นี่เป็นเพียงมุมมองของคุณ Matt เท่านั้นนะครับ โดยส่วนตัวแล้ว GraphQL ยังคงเป็นเทคโนโลยีที่มีประโยชน์ในหลายกรณี สิ่งสำคัญคือเราต้องพิจารณาข้อดี ข้อเสียอย่างรอบด้านและเลือกใช้ให้เหมาะกับบริบทของการใช้งานและความต้องการ (requirements) ของแต่ละโปรเจคท์หรือขององค์กรเรา ไม่ใช่แค่ตามกระแสหรือเพราะเป็นของใหม่หรือดู............ cool เท่านั้นครับ

อ้างอิง

• bessey.dev