เหตุผลที่เลิกใช้ GraphQL หลังผ่านมา 6 ปี

• ใช้มาตั้งแต่ปี 2018 เป็นเวลา 6 ปี เคยเป็นแฟนตัวยงของ GraphQL อย่างแท้จริง แต่ตอนนี้เริ่มมีความกังขา
• ต้องการอธิบายเหตุผลที่ตอนนี้ไม่แนะนำ GraphQL แล้ว และคิดว่าทางเลือกที่ดีกว่าคืออะไร

พื้นที่ผิวการโจมตี

• GraphQL มีความเสี่ยงที่จะขยายพื้นที่ผิวการโจมตี เพราะเปิดเผยภาษาคิวรีออกมา
• ปัญหาที่เกี่ยวข้องกับการกำหนดสิทธิ์มีความสำคัญเป็นพิเศษ
  • จำเป็นต้องมีการตรวจสอบสิทธิ์ที่เหมาะสมสำหรับทุกฟิลด์
  • ใน REST API การตรวจสอบสิทธิ์แยกตามแต่ละเอ็นด์พอยต์ทำได้ง่ายกว่า

การกำหนดสิทธิ์

• ต้องตรวจสอบสิทธิ์ของผู้ใช้สำหรับทุกฟิลด์
• ใน REST API การตรวจสอบสิทธิ์แยกตามแต่ละเอ็นด์พอยต์ทำได้ง่ายกว่า

การจำกัดอัตรา

• คิวรีของ GraphQL ไม่มีการจำกัดขนาด จึงอาจสร้างภาระหนักให้เซิร์ฟเวอร์ได้
• มีวิธีประเมินความซับซ้อนของคิวรี และจำกัดคิวรีที่เกินระดับความซับซ้อนที่กำหนด
• ใน REST API การจำกัดจำนวนคำขอทำได้ง่ายกว่า

การพาร์สคิวรี

• สตริงคิวรีที่ไม่ถูกต้องอาจทำให้หน่วยความจำของเซิร์ฟเวอร์ถูกใช้มากเกินไป
• มีวิธีตั้งค่าจำนวนข้อผิดพลาดสูงสุดเพื่อหยุดการพาร์ส

ประสิทธิภาพ

การดึงข้อมูลและปัญหา N+1

• ตัวแก้ไขฟิลด์อาจเรียกแหล่งข้อมูลภายนอกหลายครั้ง
• สามารถใช้แพตเทิร์น Dataloader เพื่อแก้ปัญหานี้ได้
• ใน REST การแก้ปัญหา N+1 ที่คอนโทรลเลอร์ทำได้ง่ายกว่า

การกำหนดสิทธิ์และปัญหา N+1

• โค้ดการกำหนดสิทธิ์อาจทำให้เกิดปัญหา N+1 ได้
• ใน REST จะไม่เกิดปัญหานี้

การยึดติดกันแน่น

• โค้ดเบสของ GraphQL มีการยึดตรรกะทางธุรกิจเข้ากับเลเยอร์การขนส่งอย่างแน่นหนา
• จำเป็นต้องมีการทดสอบแบบบูรณาการ และดีบักได้ยาก

ความซับซ้อน

• วิธีการต่าง ๆ ที่ใช้แก้ปัญหาด้านความปลอดภัยและประสิทธิภาพของ GraphQL ทำให้ความซับซ้อนของโค้ดเบสเพิ่มขึ้น
• โซลูชันแบบ REST โดยทั่วไปมักเรียบง่ายกว่า

ทางเลือก

• แนะนำ JSON REST API ที่ใช้ OpenAPI 3.0+
• หากมีไคลเอนต์ที่เขียนด้วยภาษาแบบ static type, OpenAPI อาจเป็นตัวเลือกที่ดีกว่า
• OpenAPI สามารถสร้างโค้ดไคลเอนต์แบบ type-safe ได้โดยอัตโนมัติ

ความเห็นของ GN⁺

• GraphQL ทรงพลัง แต่ต้องใช้ความพยายามมากในการแก้ปัญหาด้านความปลอดภัยและประสิทธิภาพ
• REST API ค่อนข้างเรียบง่ายกว่า และในหลายกรณีอาจเหมาะสมกว่า
• OpenAPI มอบความปลอดภัยของชนิดข้อมูลและเครื่องมืออัตโนมัติที่ช่วยเพิ่มประสิทธิภาพการพัฒนา
• เมื่อนำ GraphQL มาใช้ ควรพิจารณาปัญหาด้านความปลอดภัยและประสิทธิภาพอย่างรอบคอบ
• สิ่งสำคัญคือการเปรียบเทียบข้อดีข้อเสียของ REST กับ GraphQL แล้วเลือกเทคโนโลยีที่เหมาะกับโครงการ

[savvykang]

เหตุผลที่เลิกใช้ GraphQL หลังจากผ่านไป 6 ปี

GraphQL ค่อนข้างน่าหงุดหงิด (2022)

[yangeok]

ยุคแห่งการระบาดใหญ่ของ rpc กำลังมาถึง

[ahwjdekf]

ก็อย่างที่คิดนั่นแหละ... แค่มีอะไรที่ดู fancy ออกมาก็ไม่ควรงับแล้วอวยกันทันทีหรอก.. ทีนี้ก็ถึงคิว ORM แล้วสินะ. แกเองก็อีกไม่นานหรอก...

[rockmkd]

ORM มีมานานกว่า 20 ปีแล้วนะครับ...

[cometkim]

ถ้าเป็นปี 2018 PQ ก็คงไม่ได้ใหม่ขนาดนั้นแล้วนี่นา (จริงๆ แล้วก็มีการแนะนำมาตั้งแต่ตอนที่ GraphQL เปิดตัวครั้งแรก) เลยค่อนข้างน่าแปลกที่ไม่ได้ลองพยายามใช้มาตลอด 6 ปี...

[surfindia]

การจะลงมือทำ GraphQL ทั้งหมดด้วยตัวเองนั้นเป็นเรื่องยากทั้งในแง่ความซับซ้อนและความเสถียร ด้วยเหตุผลทั้งหมดที่กล่าวไปข้างต้น ผมคิดว่าการวางเลเยอร์อย่าง hasura หรือ postgraphile ไว้บน DB แล้วค่อยเพิ่มสิ่งที่ต้องการเข้าไปที่เลเยอร์นี้ ไม่ว่าจะเป็น graphql หรือ rest ตามความจำเป็น น่าจะเป็นวิธีพัฒนาที่ดีกว่า

[GN⁺]

ความคิดเห็นจาก Hacker News

• หลังนำ GraphQL มาใช้ก็เจอปัญหามากมาย ไม่อยากใช้ต่อแล้วเพราะปัญหาเรื่องการจัดการสิทธิ์และประสิทธิภาพ อาจเหมาะถ้าใช้แค่ฝั่งฟรอนต์เอนด์ แต่การผสานกับแบ็กเอนด์มีความซับซ้อน
• พอได้เรียนรู้ REST ก่อนแล้วลองใช้ gRPC ก็พบว่า API ที่มี type safety นั้นน่าสนใจมาก GraphQL แทบไม่มีข้อดีมากนัก และมีประโยชน์ก็ต่อเมื่อมันทำงานคล้ายฐานข้อมูล
• เคยทำงานในโปรเจกต์ GraphQL สองโปรเจกต์ ตอนแรกเริ่มเล็ก ๆ แต่เมื่อเวลาผ่านไปก็ซับซ้อนขึ้น ดีบักยากและเกิดปัญหาด้านประสิทธิภาพ REST และ RPC เรียบง่ายกว่าและดูแลง่ายกว่า
• ในฐานะผู้ก่อตั้ง Hasura ได้เห็นวิวัฒนาการของการใช้ GraphQL มาโดยตลอด GraphQL สร้างได้ยากมากหากไม่มี data layer การใช้ GraphQL ครอบบน REST ไม่มีประสิทธิภาพ กรณีใช้งานหลักของ GraphQL คือเมื่อมีผู้ใช้ข้อมูลหลายกลุ่ม
• วิศวกรฟรอนต์เอนด์เก็บคิวรีไว้ในไลบรารีส่วนกลางและนำกลับมาใช้ซ้ำ ซึ่งก็ไม่ต่างจากการใช้ GraphQL แบบเดียวกับ REST
• จากประสบการณ์ที่เคยใช้ OpenAPI, GraphQL, JSON/HTTP และ gRPC การจำกัด GraphQL query สามารถช่วยบรรเทาปัญหาด้านประสิทธิภาพและความปลอดภัยได้ Buf Connect เป็นจุดลงตัวที่เหมาะสมที่สุดสำหรับโปรเจกต์ส่วนใหญ่
• จากประสบการณ์ใช้ GraphQL ที่ Facebook หลายคนไม่ได้มีปัญหาแบบที่ GraphQL พยายามจะแก้ Facebook ใช้ GraphQL เพื่อจัดการเรื่องเวอร์ชันและโมเดลอ็อบเจ็กต์ที่ซับซ้อน
• เหตุผลที่ GraphQL ทำงานได้ดีที่ Facebook คือผู้ใช้ทุกคนล็อกอิน และความปลอดภัยถูกฝังอยู่ในทุกฟิลด์ หากเป็น SPA และมีข้อกำหนดให้ต้องล็อกอิน GraphQL ก็อาจมีประโยชน์
• ลองใช้ GraphQL แล้วพบว่าตอนแรกมันดี แต่สุดท้ายต้องมีงานเพิ่มและความซ้ำซ้อนจำนวนมาก การเริ่มจาก JSON-RPC type endpoint แล้วค่อยเพิ่มความสามารถที่ต้องการน่าจะดีกว่า
• เมื่อลองใช้ GraphQL ในโปรเจกต์เล็ก พบว่าแทบทุกอย่างดีมาก ใช้ Apollo Client และ graphql-codegen เพื่อสร้าง type และฟังก์ชันสำหรับ Vue 3 แม้จะมีปัญหาบางอย่าง แต่ก็ช่วยจับข้อผิดพลาดได้มากในระดับ type