GraphQL คืออะไร? เมื่อ REST API ไม่ตอบโจทย์อีกต่อไป

ทุกคนเคยเจอปัญหานี้ไหมครับ เวลาที่เราต้องดึงข้อมูลมาแสดงผลที่หน้าเว็บ...

หน้าโปรไฟล์ผู้ใช้: ต้องยิง API ไปที่ /users/1 เพื่อเอาข้อมูลผู้ใช้, แล้วยิงไปที่ /users/1/posts เพื่อเอารายชื่อบทความ, แล้วก็ยิงไปที่ /users/1/followers เพื่อเอาจำนวนผู้ติดตาม... โอ้โห! 3 requests! 😫
หน้าแสดงรายการสินค้า: แค่อยากได้แค่ "ชื่อ" กับ "ราคา" แต่ API ที่ /products ดันส่งข้อมูลมาให้หมดทุกอย่างเลย ทั้งรายละเอียด, น้ำหนัก, สีที่มี, รีวิว... ข้อมูลเยอะเกินความจำเป็น (Over-fetching) เฉยเลย

ถ้าเคยเจอแบบนี้... วันนี้ผมจะพาทุกคนไปรู้จักกับ GraphQL ฮีโร่ที่จะมาแก้ปัญหาเหล่านี้ครับ!

GraphQL คืออะไร? (ฉบับสั่งอาหารตามสั่ง)

ถ้าเปรียบเทียบ REST API เหมือนการไปกิน "บุฟเฟ่ต์เซ็ต" ที่ร้านจัดเซ็ตไว้ให้แล้ว เราเลือกได้แค่ว่าจะเอาเซ็ต A, B, หรือ C ซึ่งบางทีก็ได้ของที่ไม่ต้องการมาด้วย

GraphQL ก็คือการไปร้านอาหาร "ตามสั่ง" ครับ เราสามารถเดินไปบอกเชฟได้เลยว่า "เชฟครับ! ขอสเต็กเนื้อ 1 ชิ้น, ขอมันบด ไม่เอาผัก, ซอสพริกไทยดำ" เราจะได้ทุกอย่างที่เราขอ พอดีเป๊ะ ไม่มีขาด ไม่มีเกิน

สรุปง่าย ๆ ก็คือ:

GraphQL เป็น Query Language สำหรับ API ที่ให้อำนาจฝั่ง Client (Frontend) ในการ "ร้องขอ" ข้อมูลเฉพาะสิ่งที่ตัวเองต้องการเท่านั้นใน Request เดียว

แล้วมันทำงานยังไง?

แทนที่จะมีหลาย ๆ Endpoints เหมือน REST (เช่น /users, /products, /orders), GraphQL จะมี แค่ Endpoint เดียว เท่านั้น! (ปกติจะเป็น /graphql)

ฝั่ง Client จะส่ง Query (หน้าตาคล้าย ๆ JSON) ไปบอก Server ว่าอยากได้ข้อมูลอะไรบ้าง

ตัวอย่าง: ดึงข้อมูลผู้ใช้และบทความ

ลองดูสถานการณ์เดิมที่เราต้องยิง API 3 รอบใน REST นะครับ

ถ้าเป็น GraphQL เราจะเขียน Query แบบนี้:

GraphQL Query

query GetUserProfile {
  user(id: "1") {
    name
    email
    posts {
      title
      createdAt
    }
    followersCount
  }
}

แล้ว Server ก็จะตอบกลับมาเป็น JSON แบบนี้:

GraphQL Response

{
  "data": {
    "user": {
      "name": "John Doe",
      "email": "john.doe@example.com",
      "posts": [
        { "title": "My First Blog Post", "createdAt": "2025-01-01" },
        { "title": "Learning GraphQL", "createdAt": "2025-02-15" }
      ],
      "followersCount": 150
    }
  }
}

เห็นไหมครับ! เรายิง Request แค่ครั้งเดียว แต่ได้ข้อมูลครบทุกอย่างตามโครงสร้างที่เราต้องการเป๊ะ ๆ ไม่ต้องเหนื่อยยิง API หลายรอบ และไม่ต้องรับข้อมูลที่ไม่จำเป็นอีกต่อไป ชีวิตดีขึ้นเยอะเลยใช่ไหมครับ 😎

REST API vs GraphQL: ตารางเทียบหมัดต่อหมัด

เพื่อให้เห็นภาพชัดเจนขึ้น เรามาดูตารางเปรียบเทียบกันดีกว่าครับ

คุณสมบัติ	REST API	GraphQL
Endpoint	มีหลาย Endpoints ตามทรัพยากร (e.g., /users, /posts)	มีแค่ Endpoint เดียว (e.g., /graphql)
การร้องขอข้อมูล	Client ได้ข้อมูลตามที่ Server กำหนดในแต่ละ Endpoint	Client เป็นคนกำหนดโครงสร้างข้อมูลที่ต้องการเอง
ปัญหา Over/Under-fetching	เกิดขึ้นบ่อยมาก (ได้ข้อมูลเกิน หรือต้องยิงหลายรอบ)	ไม่มีปัญหานี้ เพราะขอแค่ที่ต้องการ
เอกสาร (Documentation)	ต้องใช้เครื่องมือเสริม เช่น Swagger หรือ OpenAPI	มีมาให้ในตัว (Self-documenting) ผ่าน Schema ทำให้รู้เลยว่าขออะไรได้บ้าง
การจัดการเวอร์ชัน	จัดการยาก มักจะเกิดเป็น /v1, /v2	ไม่จำเป็นต้องมีเวอร์ชัน แค่เพิ่ม Field ใหม่เข้าไปใน Schema ได้เลย (Evolving API)
การทำงานเป็นทีม	Frontend อาจต้องรอ Back-end สร้าง Endpoint ใหม่ ๆ	Frontend ทำงานต่อได้เลย ขอแค่มี Schema ที่ตกลงกันไว้
ความซับซ้อนช่วงเริ่มต้น	เข้าใจง่าย เริ่มต้นได้เร็ว	มี Learning Curve สูงกว่าในช่วงแรก เพราะต้องเข้าใจเรื่อง Schema, Query, Resolver

แล้วเราควรเลือกใช้อะไรดีล่ะ?

เลือกใช้ REST API เมื่อ:

โปรเจกต์มีขนาดเล็ก และความต้องการข้อมูลไม่ซับซ้อน
ต้องการสร้าง API Public ที่เข้าใจง่ายสำหรับคนทั่วไป
เน้นการทำ Caching ที่ระดับ HTTP เพราะทำได้ง่ายกว่า

เลือกใช้ GraphQL เมื่อ:

แอปพลิเคชันมีความซับซ้อนสูง ข้อมูลเกี่ยวโยงกันเยอะ
Frontend มีหลายแพลตฟอร์ม (Web, Mobile App) ที่ต้องการข้อมูลต่างกัน
ต้องการลดจำนวน Network Request เพื่อ Performance ที่ดีขึ้น (โดยเฉพาะบนมือถือ)
ทีม Frontend ต้องการความยืดหยุ่นในการทำงาน โดยไม่ต้องรอทีม Back-end

หวังว่าบทความนี้จะช่วยให้ทุกคน เข้าใจ GraphQL มากขึ้น และเห็นภาพว่ามันจะเข้ามาช่วยแก้ปัญหาในการพัฒนาได้อย่างไร แม้ช่วงแรกอาจจะต้องเรียนรู้เยอะหน่อย แต่ผลลัพธ์ที่ได้นั้นคุ้มค่าแน่นอนครับ