นิยามแบบสั้นแต่ลึก
GraphQL คือภาษาสำหรับสอบถามข้อมูล (Query Language) และรันไทม์สำหรับ API ที่ถูกพัฒนาโดย Meta (เดิมชื่อ Facebook) ตั้งแต่ปี 2015 จุดเด่นคือทำให้ฝั่ง Frontend สามารถ "ขอข้อมูลเฉพาะที่ต้องการ" ได้ในคำขอเดียว แทนที่จะต้องยิงหลาย endpoint แล้วได้ข้อมูลเกินจำเป็นแบบ REST
พูดแบบคนทำร้านออนไลน์: ถ้า REST คือการสั่งอาหารแบบ "ชุดเซ็ต" ที่ได้ของที่ไม่ได้กินติดมาด้วย GraphQL คือการสั่งแบบ "à la carte" เลือกได้ทีละอย่างตามใจ
ในสถาปัตยกรรม Headless Commerce เช่น Shopify Storefront API, BigCommerce GraphQL API, Commerce Layer หรือ Saleor — GraphQL คือหัวใจที่ทำให้ Frontend (Next.js, Nuxt, Hydrogen) ดึงสินค้า, ราคา, สต็อก, โปรโมชัน มาประกอบหน้าเว็บได้อย่างแม่นยำ
อุปมาที่คนไทยเข้าใจง่าย
ลองนึกภาพ "ตลาดนัด" กับ "เซเว่นฯ"
- REST = เซเว่นฯ แต่ละสาขาขายของตายตัว คุณอยากได้น้ำเปล่า + ขนม ต้องเดินไป 2 สาขา (2 endpoint) บางทีซื้อขนมมาแล้วแถมถุงเยอะโดยไม่ต้องใช้
- GraphQL = ตลาดนัดที่คุณยื่นใบสั่งครั้งเดียว บอกว่า "เอาสินค้า 10 ชิ้น เอาแค่ชื่อ ราคา และรูปแรก" พ่อค้าก็จัดให้ตรงนั้น จบในคำขอเดียว
สำหรับร้าน DTC ที่มีหน้า Category, PDP, Cart, Checkout — GraphQL ช่วยลด round-trip ระหว่าง Frontend กับ Backend ได้มาก บน 4G ไทยที่บางพื้นที่ยังช้า การลด request จาก 6 ครั้งเหลือ 1 ครั้ง ส่งผลต่อ Conversion โดยตรง
หลักการทำงาน (สูตรและโครงสร้าง)
GraphQL มี 3 operation หลัก:
query → อ่านข้อมูล (GET) mutation → เขียน/แก้ข้อมูล (POST/PUT/DELETE) subscription → รับข้อมูลแบบ real-time (WebSocket)
ตัวอย่าง query จริงในบริบทอีคอมเมิร์ซ:
query {
product(id: "SKU-12345") {
title
price { amount currencyCode }
variants(first: 5) {
edges { node { id sku quantityAvailable } }
}
}
}
สูตรคิดต้นทุนคำขอ (Payload Reduction):
Payload Reduction (%) = ((REST Payload − GraphQL Payload) / REST Payload) × 100
ตัวอย่างจริง: ถ้า REST คืน JSON 480 KB แต่ GraphQL คืนแค่ 62 KB
→ ลด payload ได้ (480 − 62) / 480 × 100 = 87.1%
นี่คือเหตุผลที่แบรนด์ DTC อย่าง Allbirds, Gymshark และแบรนด์ไทยที่ใช้ Shopify Hydrogen รายงานว่า LCP (Largest Contentful Paint) ดีขึ้น 30–50%
ตารางเปรียบเทียบ REST vs GraphQL
| หัวข้อ | REST API | GraphQL API |
|---|---|---|
| จำนวน Endpoint | หลายตัว เช่น `/products`, `/cart`, `/orders` | มักมีจุดเดียว เช่น `/graphql` |
| การดึงข้อมูล | ได้ตามที่ Server กำหนด (over-fetching) | เลือก field ได้เอง (no over-fetching) |
| จำนวน Request ต่อหน้า PDP | 4–8 ครั้ง | 1–2 ครั้ง |
| Versioning | `/v1/`, `/v2/` | ใช้ Schema Evolution ไม่ต้อง version |
| Caching | ง่าย (HTTP cache ตาม URL) | ซับซ้อน ต้องใช้ persisted query / CDN เฉพาะทาง |
| Learning Curve | ต่ำ | ปานกลาง–สูง |
| เหมาะกับ | ระบบเรียบง่าย, Webhook | Headless Commerce, Mobile App, Multi-platform |
ตัวเลขที่ควรรู้ก่อนตัดสินใจใช้
1. Request Reduction ต่อหน้า PDP: จาก 6 requests (REST) → 1 request (GraphQL) = ลด 83%
2. Payload Size: เฉลี่ยลดจาก 350–500 KB เหลือ 50–90 KB = ประหยัด bandwidth ประมาณ 80%
3. TTFB บน mobile 4G ไทย: ปรับจาก ~820 ms เหลือ ~410 ms หลังย้ายมาใช้ GraphQL + CDN edge (อ้างอิงจากเคส Shopify Hydrogen)
ใช้จริงในธุรกิจ DTC ไทยแบบไหน
- Headless Storefront: ใช้ Shopify Storefront API (GraphQL) ดึงสินค้าไปโชว์บน Next.js แล้ว deploy บน Vercel
- Mobile App: แอปสมาชิกของแบรนด์ดึงข้อมูล user + order history + point สะสม ในคำขอเดียว
- Cart & Checkout: ใช้ mutation เพื่อ add/update/remove line items แบบ atomic
- Personalization: รวมข้อมูล recommendation + stock + ราคาโปรเฉพาะคน ใน query เดียว
- Omnichannel: ใช้ schema เดียวกันป้อนทั้งเว็บ, แอป, LINE LIFF, และ in-store kiosk
ข้อเข้าใจผิดที่พบบ่อย
1. "GraphQL แทนที่ REST ได้ทั้งหมด" — ไม่จริง งานอย่าง file upload, webhook, หรือ public API ที่ต้อง cache ง่ายๆ REST ยังได้เปรียบ
2. "GraphQL เร็วกว่าเสมอ" — เร็วเพราะลด request แต่ถ้า resolver เขียนไม่ดี (N+1 problem) จะช้ากว่า REST ด้วยซ้ำ ต้องใช้ DataLoader
3. "ปลอดภัยโดยธรรมชาติ" — ต้องจำกัด query depth, จำกัด complexity, ปิด introspection บน production
4. "ใช้แล้วไม่ต้องทำ caching" — ต้องใช้ Persistent Query, CDN, หรือ Apollo Cache ไม่งั้น server รับภาระหนัก
5. "เขียน Schema ยาก" — จริงแค่ช่วงแรก แต่พอ schema นิ่งแล้ว การเพิ่ม field ใหม่ไม่กระทบ client เดิมเลย
คำศัพท์ที่เกี่ยวข้อง
- Schema — โครงสร้างข้อมูลที่ประกาศว่ามี type อะไรบ้าง
- Resolver — ฟังก์ชันที่บอกว่าจะดึงข้อมูล field นั้นมาจากไหน
- Apollo Client / urql — ไลบรารีฝั่ง Frontend สำหรับเรียก GraphQL
- DataLoader — เครื่องมือแก้ปัญหา N+1 ใน resolver
- Persisted Query — ส่ง hash แทน query เต็ม เพื่อลด payload และเพิ่มความปลอดภัย
- Storefront API — GraphQL endpoint สำหรับหน้าร้านของ Shopify
- Headless Commerce — สถาปัตยกรรมที่แยก Frontend ออกจาก Backend
- REST — สถาปัตยกรรม API แบบเดิมที่ GraphQL เข้ามาเสริม
- Federation — การรวมหลาย GraphQL service เป็น graph เดียว (เหมาะกับองค์กรใหญ่)
สรุปสั้นๆ: ถ้าคุณทำ DTC แล้วกำลังมองหา Headless, Mobile App หรือ Omnichannel — GraphQL คือเครื่องมือที่ช่วยให้ Frontend เร็วขึ้น ลด bandwidth และยืดหยุ่นกว่า REST อย่างชัดเจน แต่ต้องลงทุนเรื่อง caching, security และทีมที่มีความเข้าใจ schema จริงจัง
