GraphQL คืออะไร? สอน GraphQL ตั้งแต่เริ่มต้น เปรียบเทียบกับ REST API สำหรับ Developer 2026

ในโลกของ API Development ปี 2026 GraphQL กลายเป็นเทคโนโลยีที่ได้รับความนิยมเพิ่มขึ้นอย่างต่อเนื่อง ตั้งแต่ Facebook เปิดตัวเป็น Open Source ในปี 2015 จนถึงวันนี้ บริษัทยักษ์ใหญ่อย่าง GitHub, Shopify, Twitter, Netflix และ Airbnb ต่างนำ GraphQL มาใช้ในระบบ Production ของตัวเอง บทความนี้จะสอน GraphQL ตั้งแต่เริ่มต้นจนถึงระดับ Advanced เปรียบเทียบกับ REST API อย่างละเอียด พร้อมตัวอย่างโค้ดที่ใช้งานได้จริงทั้ง Server และ Client side

GraphQL คืออะไร?

GraphQL (Graph Query Language) คือภาษาสำหรับ Query ข้อมูลจาก API ที่พัฒนาโดย Facebook ในปี 2012 และเปิดเป็น Open Source ในปี 2015 แนวคิดหลักของ GraphQL คือให้ Client เป็นคนกำหนดว่าต้องการข้อมูลอะไรบ้าง แทนที่จะให้ Server เป็นคนกำหนดรูปแบบข้อมูลที่จะส่งกลับมาเหมือน REST API แบบเดิม

อ่านเพิ่ม: gRPC และ Protocol Buffers คืออะไร? สอนสร้าง High-Performance · อ่านเพิ่ม: Supabase คืออะไร? ทางเลือก Firebase แบบ Open Source สำหรับ F · อ่านเพิ่ม: Java และ Spring Boot คืออะไร? สอนสร้าง Backend API ด้วย Spri

GraphQL ไม่ใช่ Database และไม่ใช่ Framework แต่เป็น Specification ที่กำหนดวิธีการสื่อสารระหว่าง Client กับ Server โดยมีคุณสมบัติสำคัญดังนี้:

• Single Endpoint — ใช้ URL เดียว (เช่น /graphql) สำหรับทุก Operation ต่างจาก REST ที่มีหลาย Endpoint
• Declarative Data Fetching — Client ระบุว่าต้องการ Field อะไรบ้าง Server ส่งกลับเฉพาะสิ่งที่ขอ
• Strongly Typed Schema — มี Type System ที่ชัดเจน ทำให้ตรวจสอบ Query ได้ก่อน Execute
• Introspection — Client สามารถ Query Schema ของ API ได้ ทำให้เครื่องมืออย่าง GraphQL Playground สร้าง Documentation อัตโนมัติ
• Hierarchical — โครงสร้าง Query เป็นแบบ Tree ตรงกับโครงสร้างข้อมูลที่ต้องการ

GraphQL vs REST API — เปรียบเทียบอย่างละเอียด

เพื่อให้เข้าใจว่า GraphQL แก้ปัญหาอะไรของ REST ลองดูตัวอย่างสถานการณ์จริง สมมติเราต้องการแสดงข้อมูลโปรไฟล์ผู้ใช้ที่มี ชื่อ, อีเมล, โพสต์ล่าสุด 5 รายการ และจำนวน Followers

เนื้อหาเกี่ยวข้อง — Kubernetes Admission Webhook Cloud Native Design

แบบ REST API (หลาย Request)

# Request 1: ข้อมูลผู้ใช้
GET /api/users/123
# Response: ได้ข้อมูลทั้งหมดของ User (ทั้งที่ต้องการแค่ name, email)
# Over-fetching: ได้ address, phone, settings มาด้วยทั้งที่ไม่ต้องการ

# Request 2: โพสต์ของผู้ใช้
GET /api/users/123/posts?limit=5
# Response: ได้โพสต์พร้อม field ที่ไม่ต้องการ

# Request 3: จำนวน Followers
GET /api/users/123/followers/count
# Response: ได้จำนวน followers

# ปัญหา: 3 Requests, Over-fetching, Under-fetching

แบบ GraphQL (Request เดียว)

# Request เดียว — ได้ข้อมูลเฉพาะที่ต้องการ
query {
  user(id: "123") {
    name
    email
    posts(limit: 5) {
      title
      createdAt
    }
    followersCount
  }
}

# Response: ได้เฉพาะ field ที่ขอเท่านั้น ไม่เกินไม่ขาด

Schema Definition — หัวใจของ GraphQL

Schema คือ Contract ระหว่าง Client กับ Server ที่กำหนดว่า API มีข้อมูลอะไรบ้าง Query อะไรได้ และ Mutate อะไรได้ Schema เขียนด้วย SDL (Schema Definition Language)

Scalar Types (ชนิดข้อมูลพื้นฐาน)

# Built-in Scalar Types
Int       # จำนวนเต็ม 32-bit
Float     # ทศนิยม
String    # ข้อความ UTF-8
Boolean   # true/false
ID        # Unique Identifier (เก็บเป็น String)

# Custom Scalar (สร้างเอง)
scalar DateTime
scalar Email
scalar URL
scalar JSON

Object Types

# กำหนด Type ของข้อมูล
type User {
  id: ID!                    # ! = non-nullable (ต้องมีค่า)
  name: String!
  email: String!
  age: Int
  bio: String
  avatar: URL
  posts: [Post!]!            # Array ของ Post (ทั้ง Array และ Item ต้องไม่เป็น null)
  followers: [User!]!
  followersCount: Int!
  createdAt: DateTime!
}

type Post {
  id: ID!
  title: String!
  content: String!
  published: Boolean!
  author: User!              # Relationship กลับไปหา User
  tags: [Tag!]!
  comments: [Comment!]!
  likes: Int!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Comment {
  id: ID!
  text: String!
  author: User!
  post: Post!
  createdAt: DateTime!
}

type Tag {
  id: ID!
  name: String!
  posts: [Post!]!
}

Enum Types

enum Role {
  ADMIN
  EDITOR
  USER
  GUEST
}

enum PostStatus {
  DRAFT
  PUBLISHED
  ARCHIVED
}

type User {
  id: ID!
  name: String!
  role: Role!
}

Input Types (สำหรับ Arguments)

input CreateUserInput {
  name: String!
  email: String!
  age: Int
  role: Role = USER          # Default value
}

input UpdateUserInput {
  name: String
  email: String
  age: Int
  bio: String
}

input PostFilterInput {
  status: PostStatus
  tag: String
  authorId: ID
  searchTerm: String
}

Interface และ Union Types

# Interface — ใช้เมื่อหลาย Type มี field ร่วมกัน
interface Node {
  id: ID!
  createdAt: DateTime!
}

type User implements Node {
  id: ID!
  createdAt: DateTime!
  name: String!
  email: String!
}

type Post implements Node {
  id: ID!
  createdAt: DateTime!
  title: String!
  content: String!
}

# Union — ใช้เมื่อ field อาจเป็นได้หลาย Type
union SearchResult = User | Post | Comment

type Query {
  search(term: String!): [SearchResult!]!
}

Queries, Mutations และ Subscriptions

GraphQL มี Operation 3 ประเภทหลัก:

แนะนำเพิ่มเติม — แหล่งความรู้ Forex iCafeForex

1. Query — อ่านข้อมูล

# Schema definition
type Query {
  user(id: ID!): User
  users(limit: Int, offset: Int): [User!]!
  post(id: ID!): Post
  posts(filter: PostFilterInput): [Post!]!
  me: User                   # ผู้ใช้ปัจจุบัน (จาก token)
}

# Client query
query GetUserProfile {
  user(id: "123") {
    name
    email
    posts(limit: 5) {
      title
      createdAt
      comments {
        text
        author {
          name
        }
      }
    }
  }
}

# Query with multiple root fields
query Dashboard {
  me {
    name
    role
  }
  recentPosts: posts(filter: { status: PUBLISHED }) {
    title
    likes
  }
  totalUsers: users {
    id
  }
}

2. Mutation — เปลี่ยนแปลงข้อมูล

# Schema definition
type Mutation {
  createUser(input: CreateUserInput!): User!
  updateUser(id: ID!, input: UpdateUserInput!): User!
  deleteUser(id: ID!): Boolean!
  createPost(title: String!, content: String!, tags: [String!]): Post!
  likePost(id: ID!): Post!
  addComment(postId: ID!, text: String!): Comment!
}

# Client mutation
mutation CreateNewUser {
  createUser(input: {
    name: "สมชาย"
    email: "somchai@example.com"
    age: 28
    role: USER
  }) {
    id
    name
    email
    createdAt
  }
}

mutation UpdateMyProfile {
  updateUser(id: "123", input: {
    name: "สมชาย ใจดี"
    bio: "Full-stack Developer"
  }) {
    id
    name
    bio
  }
}

3. Subscription — รับข้อมูลแบบ Real-time

# Schema definition
type Subscription {
  postCreated: Post!
  commentAdded(postId: ID!): Comment!
  userOnlineStatus(userId: ID!): OnlineStatus!
}

type OnlineStatus {
  userId: ID!
  isOnline: Boolean!
  lastSeen: DateTime
}

# Client subscription (ใช้ WebSocket)
subscription OnNewComment {
  commentAdded(postId: "456") {
    text
    author {
      name
      avatar
    }
    createdAt
  }
}

Resolvers — ตัวดึงข้อมูลจริง

Resolver คือฟังก์ชันที่รับผิดชอบในการดึงข้อมูลสำหรับแต่ละ Field ใน Schema เมื่อ Client ส่ง Query มา GraphQL Server จะเรียก Resolver ที่เกี่ยวข้องเพื่อสร้าง Response

Apollo Server — สร้าง GraphQL Server ด้วย Node.js

Apollo Server เป็น Library ที่ได้รับความนิยมสูงสุดสำหรับสร้าง GraphQL Server บน Node.js มาดูวิธีเริ่มต้นจากศูนย์

เนื้อหาเกี่ยวข้อง — แนะนำให้อ่าน Nextra MDX CI CD Automation Pipeline

ติดตั้งและตั้งค่าเบื้องต้น

# สร้างโปรเจกต์
mkdir graphql-server && cd graphql-server
npm init -y
npm install @apollo/server graphql

# สำหรับ Database
npm install @prisma/client prisma
npx prisma init

ตัวอย่าง Server แบบสมบูรณ์

Apollo Client — ใช้ GraphQL ฝั่ง React

Apollo Client เป็น Library สำหรับจัดการ GraphQL ฝั่ง Client ที่ได้รับความนิยมสูงสุด มี Built-in Cache, Loading/Error States และรองรับ TypeScript อย่างดี

Fragments — ใช้ Field ซ้ำ

Fragment ช่วยให้เราสร้างชุด Field ที่ใช้ซ้ำบ่อยๆ ลดการเขียนโค้ดซ้ำ และทำให้ Query อ่านง่ายขึ้น เหมาะสำหรับโปรเจกต์ขนาดใหญ่ที่มีหลาย Component ใช้ข้อมูลคล้ายกัน

# กำหนด Fragment
fragment UserBasicInfo on User {
  id
  name
  email
  avatar
}

fragment PostSummary on Post {
  id
  title
  createdAt
  likes
  author {
    ...UserBasicInfo
  }
}

# ใช้ Fragment ใน Query
query GetDashboard {
  me {
    ...UserBasicInfo
    role
    posts {
      ...PostSummary
    }
  }
  recentPosts {
    ...PostSummary
    comments {
      text
      author {
        ...UserBasicInfo
      }
    }
  }
}

# Inline Fragment (สำหรับ Union/Interface)
query Search {
  search(term: "GraphQL") {
    ... on User {
      name
      email
    }
    ... on Post {
      title
      content
    }
    ... on Comment {
      text
    }
  }
}

Variables และ Directives

Variables — ส่ง Parameter แบบ Dynamic

# ใช้ Variable แทนค่าตรง (Hardcode)
query GetUser($userId: ID!, $includeEmail: Boolean = true) {
  user(id: $userId) {
    name
    email @include(if: $includeEmail)
    posts {
      title
    }
  }
}

# Variables (ส่งเป็น JSON แยก)
# {
#   "userId": "123",
#   "includeEmail": true
# }

Directives — ควบคุม Query แบบมีเงื่อนไข

# Built-in Directives
@include(if: Boolean)   # รวม field ถ้า true
@skip(if: Boolean)      # ข้าม field ถ้า true
@deprecated(reason: String)  # ทำเครื่องหมาย field ที่เลิกใช้

# ตัวอย่างใน Schema
type User {
  id: ID!
  name: String!
  email: String!
  username: String @deprecated(reason: "Use 'name' instead")
}

# ตัวอย่างใน Query
query GetUser($userId: ID!, $withPosts: Boolean!) {
  user(id: $userId) {
    name
    email
    posts @include(if: $withPosts) {
      title
    }
  }
}

# Custom Directive (Server-side)
directive @auth(requires: Role!) on FIELD_DEFINITION

type Query {
  publicPosts: [Post!]!
  adminDashboard: Dashboard! @auth(requires: ADMIN)
  userSettings: Settings! @auth(requires: USER)
}

Pagination — จัดการข้อมูลจำนวนมาก

เมื่อมีข้อมูลจำนวนมาก การดึงทั้งหมดในครั้งเดียวไม่เหมาะสม GraphQL มี Pattern การทำ Pagination 2 แบบหลัก คือ Offset-based และ Cursor-based

แนะนำเพิ่มเติม — XM Signal

Offset-based Pagination (ง่าย แต่มีข้อจำกัด)

type Query {
  posts(limit: Int = 10, offset: Int = 0): PostConnection!
}

type PostConnection {
  items: [Post!]!
  totalCount: Int!
  hasMore: Boolean!
}

# Query
query {
  posts(limit: 10, offset: 20) {
    items {
      title
      createdAt
    }
    totalCount
    hasMore
  }
}

# ข้อเสีย: ถ้ามีการเพิ่ม/ลบข้อมูลระหว่าง pagination
# อาจเจอข้อมูลซ้ำหรือหายไป

Cursor-based Pagination (แนะนำ — Relay Style)

# Relay-style Connection specification
type Query {
  posts(first: Int, after: String, last: Int, before: String): PostConnection!
}

type PostConnection {
  edges: [PostEdge!]!
  pageInfo: PageInfo!
  totalCount: Int!
}

type PostEdge {
  cursor: String!       # Unique identifier สำหรับ position
  node: Post!           # ข้อมูลจริง
}

type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
  startCursor: String
  endCursor: String
}

# Query — ขอ 10 รายการแรก
query {
  posts(first: 10) {
    edges {
      cursor
      node {
        title
        createdAt
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

# Query — ขอ 10 รายการถัดไป (ใช้ endCursor จากก่อนหน้า)
query {
  posts(first: 10, after: "cursor_abc123") {
    edges {
      cursor
      node {
        title
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Error Handling ใน GraphQL

GraphQL จัดการ Error ต่างจาก REST API ตรงที่ GraphQL จะคืน HTTP 200 เสมอ (ยกเว้น Server Error จริงๆ) และรายงาน Error ผ่าน errors Array ใน Response

เนื้อหาเกี่ยวข้อง — GCP Vertex AI Docker Container Deploy

Authentication และ Authorization

การทำ Auth ใน GraphQL มักใช้ Context เพื่อส่งข้อมูล User ไปยังทุก Resolver

N+1 Problem และ DataLoader

N+1 Problem เป็นปัญหาที่พบบ่อยที่สุดใน GraphQL เกิดขึ้นเมื่อ Query ข้อมูลที่มี Relationship ทำให้เกิด Database Query จำนวนมากเกินจำเป็น

Caching Strategies

การทำ Caching ใน GraphQL ซับซ้อนกว่า REST เพราะใช้ POST Request ทำให้ HTTP Cache ใช้ไม่ได้ตรงๆ ต้องอาศัยกลยุทธ์เฉพาะ

Schema Stitching และ Federation

เมื่อระบบขยายใหญ่ขึ้น การมี GraphQL Schema เดียวที่รวมทุกอย่างจะจัดการยาก Schema Stitching และ Federation ช่วยแบ่ง Schema ออกเป็นส่วนๆ

เนื้อหาเกี่ยวข้อง — แนะนำให้อ่าน MongoDB Change Streams Domain Driven Design DDD

Apollo Federation (แนะนำสำหรับ Microservices)

# Service: Users
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

# Service: Posts
type Post {
  id: ID!
  title: String!
  author: User!    # Reference ข้าม Service
}

# Extend User ใน Posts Service
extend type User @key(fields: "id") {
  id: ID! @external
  posts: [Post!]!            # เพิ่ม field ให้ User
}

# Apollo Gateway (รวมทุก Subgraph)
import { ApolloGateway } from '@apollo/gateway';

const gateway = new ApolloGateway({
  supergraphSdl: '...',  // หรือ
  subgraphs: [
    { name: 'users', url: 'http://users:4001/graphql' },
    { name: 'posts', url: 'http://posts:4002/graphql' },
    { name: 'comments', url: 'http://comments:4003/graphql' },
  ],
});

เครื่องมือสำหรับ GraphQL

เมื่อไหร่ควรใช้ GraphQL vs REST?

ใช้ GraphQL เมื่อ:

• Client หลายตัว (Mobile, Web, TV) ต้องการข้อมูลต่างกัน
• ข้อมูลมี Relationship ซับซ้อน (Graph-like data)
• ต้องการลด Network Requests (รวมหลาย Resource ใน Query เดียว)
• ต้องการ API ที่ Evolve ได้โดยไม่ต้อง Version
• ทีมใหญ่ที่ Frontend-Backend ต้องการ Contract ที่ชัดเจน
• ใช้ BFF (Backend For Frontend) Pattern

ใช้ REST เมื่อ:

• CRUD ง่ายๆ ที่ไม่มี Relationship ซับซ้อน
• ต้องการ HTTP Caching (CDN, Browser Cache)
• File Upload/Download เป็นหลัก
• Public API ที่ต้องการความเรียบง่าย
• ทีมไม่คุ้นเคย GraphQL และโปรเจกต์เร่งด่วน
• Webhook หรือ Server-to-Server Communication

Performance Considerations

Persisted Queries

// Client ส่ง hash แทน query string เต็ม
// ลดขนาด request + ป้องกัน arbitrary queries

// ขั้นตอน: 1) Build time — extract queries เป็น hash
//          2) Runtime — client ส่ง hash, server lookup query จาก hash

// Apollo Automatic Persisted Queries (APQ)
import { ApolloClient, InMemoryCache } from '@apollo/client';
import { createPersistedQueryLink } from '@apollo/client/link/persisted-queries';
import { createHttpLink } from '@apollo/client/link/http';
import { sha256 } from 'crypto-hash';

const link = createPersistedQueryLink({ sha256 }).concat(
  createHttpLink({ uri: '/graphql' })
);

const client = new ApolloClient({ link, cache: new InMemoryCache() });

Best Practices สำหรับ GraphQL ในระบบ Production

• ใช้ DataLoader เสมอ — แก้ N+1 Problem ตั้งแต่เริ่มต้น อย่ารอจนมีปัญหา Performance
• ใช้ Persisted Queries — ลดขนาด Request และป้องกัน Query Injection
• จำกัด Query Depth และ Complexity — ป้องกันผู้ใช้ส่ง Query ที่ทำให้ Server ล่ม
• ใช้ TypeScript + Codegen — สร้าง Types อัตโนมัติจาก Schema ลด Bug จาก Type mismatch
• Schema Design First — ออกแบบ Schema ก่อนเขียน Code ให้ Frontend-Backend ตกลง Contract กัน
• Error Handling ที่ดี — ใช้ Error Code ที่ชัดเจน (UNAUTHENTICATED, NOT_FOUND, FORBIDDEN) ไม่ใช่แค่ Message
• Monitoring — ติดตาม Query Performance, Error Rate, Slow Resolvers ด้วย Apollo Studio หรือเครื่องมืออื่น
• Pagination ตั้งแต่เริ่มต้น — อย่าส่ง List ทั้งหมดโดยไม่มี Limit
• Deprecate อย่า Delete — ใช้ @deprecated directive แทนการลบ Field ออกทันที
• Cache อย่างเหมาะสม — ใช้ Apollo Client Cache + Server-side Cache (Redis) ร่วมกัน

สรุป

GraphQL เป็นเทคโนโลยีที่ทรงพลังสำหรับการสร้าง API ที่ยืดหยุ่นและมีประสิทธิภาพ ด้วย Type System ที่แข็งแกร่ง การดึงข้อมูลที่แม่นยำ และเครื่องมือที่ครบครัน ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับแอปพลิเคชันที่มีข้อมูลซับซ้อนหรือต้องรองรับ Client หลายตัว

อย่างไรก็ตาม GraphQL ไม่ได้เหมาะกับทุกสถานการณ์ สำหรับ API ที่เรียบง่าย REST ยังคงเป็นตัวเลือกที่ดี สิ่งสำคัญคือเข้าใจข้อดีข้อเสียของทั้งสอง แล้วเลือกใช้ให้เหมาะกับความต้องการของโปรเจกต์ เริ่มต้นลองสร้าง Apollo Server ง่ายๆ ลองเขียน Schema และ Query แล้วคุณจะเห็นว่า GraphQL เปลี่ยนวิธีคิดเกี่ยวกับ API อย่างไร