PHP Academy · บทเรียน

GraphQL เทียบกับ REST

ทำความเข้าใจว่าเมื่อใด GraphQL เหนือกว่า REST และเพราะเหตุใด

GraphQL เทียบกับ REST เป็นบทเรียน PHP Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน PHP Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส PHP Academy มีบทเรียนทั้งหมด 4 บทเรียน

ทำไมต้องใช้ GraphQL

คุณทราบวิธีส่งมอบ API แบบ REST ใน PHP อยู่แล้ว GraphQL ไม่ใช่สิ่งทดแทน HTTP หรือยาวิเศษ แต่เป็นภาษาสำหรับสอบถามและระบบชนิดข้อมูลที่ทำให้ไคลเอ็นต์ระบุสิ่งที่ต้องการได้อย่างแม่นยำ และได้รับกลับมาเพียงสิ่งนั้นในการเดินทางไปกลับครั้งเดียว

ในบทเรียนนี้เราจะเปรียบเทียบทั้งสองอย่างอย่างตรงไปตรงมา ว่า GraphQL มีข้อได้เปรียบจริงตรงไหน REST ยังเป็นตัวเลือกที่เหมาะสมเมื่อใด และ GraphQL มีต้นทุนด้านการปฏิบัติการอะไรบ้าง

การดึงข้อมูลเกินและการดึงข้อมูลไม่พอ

จุดเจ็บปวดแบบดั้งเดิมของ REST:

การดึงข้อมูลเกิน: GET /users/1 ส่งคืน 40 ฟิลด์ ทั้งที่ส่วนติดต่อผู้ใช้ต้องการเพียง 3 ฟิลด์
การดึงข้อมูลไม่พอ: หากต้องการแสดงโพสต์ของผู้ใช้และจำนวนความคิดเห็นของแต่ละโพสต์ คุณจะเรียก /users/1 จากนั้น /users/1/posts แล้วจึงเรียกจุดปลายทางความคิดเห็นอีก N จุด

GraphQL รวมทั้งหมดนี้เป็นคำขอเชิงประกาศเพียงครั้งเดียว

query {
  user(id: 1) {
    name
    posts {
      title
      commentCount
    }
  }
}

จุดปลายทางเดียว สคีมาที่มีชนิดข้อมูล

REST เปิดเผย URL จำนวนมาก ส่วน GraphQL เปิดเผยจุดปลายทางเดียว (โดยทั่วไปคือ POST /graphql) ซึ่งมีสคีมาที่กำหนดชนิดข้อมูลอย่างเข้มงวดรองรับอยู่ สคีมาคือสัญญา โดยสามารถตรวจสอบรายละเอียดภายในได้ ดังนั้นเครื่องมือ (การเติมข้อความอัตโนมัติ เอกสาร การสร้างโค้ด) จึงพร้อมใช้โดยไม่ต้องทำเพิ่ม

ด้านล่างคือสคีมาขั้นต่ำใน SDL รูปแบบของการตอบกลับที่เป็นไปได้ทุกแบบเป็นที่ทราบล่วงหน้า

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

type Post {
  id: ID!
  title: String!
  commentCount: Int!
}

type Query {
  user(id: ID!): User
}

ผลลัพธ์สะท้อนคำขอ

คุณสมบัติสำคัญคือ รูปแบบการตอบกลับ JSON สามารถคาดเดาได้จากคำขอ ไคลเอ็นต์ไม่ต้องเดาชื่อฟิลด์อีกต่อไป วิธีนี้ขจัดปัญหาการเปลี่ยนแปลงรุ่นจำนวนมากได้ทั้งชุด คุณสามารถเพิ่มฟิลด์โดยไม่ทำให้ไคลเอ็นต์รุ่นเก่าใช้งานไม่ได้ และเลิกใช้ฟิลด์ด้วย @deprecated แทนการตัด URL /v2 ทิ้ง

{
  "data": {
    "user": {
      "name": "Ada",
      "posts": [
        { "title": "On Engines", "commentCount": 12 }
      ]
    }
  }
}

จุดที่ GraphQL เหนือกว่า REST

GraphQL เป็นตัวเลือกที่เหมาะกว่าเมื่อ:

คุณให้บริการไคลเอ็นต์หลายประเภทที่แตกต่างกัน (เว็บ, iOS, Android) ซึ่งมีความต้องการข้อมูลต่างกัน
ข้อมูลมีลักษณะเป็นกราฟที่มีความสัมพันธ์เชิงลึก และไคลเอ็นต์สำรวจได้แบบไดนามิก
คุณต้องการรวมข้อมูลจากแบ็กเอนด์หลายแห่งไว้หลังเกตเวย์ที่มีชนิดข้อมูลกำกับเพียงแห่งเดียว
การปรับส่วนหน้าอย่างรวดเร็วมีความสำคัญ และคุณต้องการหลีกเลี่ยงการเปลี่ยนจุดปลายทางฝั่งแบ็กเอนด์ไม่รู้จบ

จุดที่ REST ยังคงเหนือกว่า

อย่าเลือกใช้ GraphQL โดยอัตโนมัติ REST จะเรียบง่ายกว่าและมักเหมาะสมกว่าเมื่อ:

คุณต้องการ การแคช HTTP — แคชของ CDN/เอดจ์ใช้ URL และเมธอดเป็นคีย์ ส่วน POST /graphql เดียวจะไม่เปิดเผยข้อมูลที่แคชเหล่านั้นต้องใช้
API เน้นทรัพยากรและมีเสถียรภาพ (CRUD กับเอนทิตีไม่กี่รายการ)
คุณต้องพึ่งพา การอัปโหลด/ดาวน์โหลดไฟล์ หรือการสตรีมข้อมูล ซึ่ง REST รองรับข้อมูลหลายส่วนและช่วงไบต์เป็นความสามารถหลัก
ผู้ใช้ API ของคุณเป็นบุคคลที่สามซึ่งคาดหวังความหมายตามแบบแผนของ REST

การเปรียบเทียบ PHP แบบสั้น ๆ

นี่คือการประกอบข้อมูลชุดเดียวกันด้วยแนวทาง REST ใน PHP — โปรดสังเกตว่าไคลเอ็นต์ยังคงต้องเรียกหลายครั้ง หรือคุณต้องสร้างพารามิเตอร์สำหรับฝังข้อมูลขึ้นเอง แต่ GraphQL ย้ายตรรกะการเลือกข้อมูลดังกล่าวไปไว้ที่ไคลเอ็นต์แทน

<?php
// REST: server decides the payload shape
function userResource(int $id): array {
    return [
        'id' => $id,
        'name' => 'Ada',
        'email' => 'ada@example.com',   // over-fetched by mobile
        'createdAt' => '1815-12-10',
        'posts' => [                       // pre-embedded, all-or-nothing
            ['title' => 'On Engines', 'commentCount' => 12],
        ],
    ];
}

header('Content-Type: application/json');
echo json_encode(userResource(1), JSON_PRETTY_PRINT);

ต้นทุนที่ GraphQL เพิ่มเข้ามา

GraphQL ย้ายความซับซ้อนไปไว้ที่เซิร์ฟเวอร์ ข้อกังวลใหม่ที่คุณต้องรับผิดชอบมีดังนี้:

คิวรี N+1 — รีโซลเวอร์แบบซ้อนจะเรียกคิวรีฐานข้อมูลหนึ่งครั้งต่อโหนด หากไม่ทำเป็นชุด (DataLoader)
การจำกัดต้นทุน/ความลึกของคิวรี — คิวรีแบบซ้อนลึกที่เป็นอันตรายอาจทำให้บริการของคุณปฏิเสธการให้บริการ (DoS)
การแคช ทำได้ยากขึ้น โดยทั่วไปคุณจะแคชที่ชั้นรีโซลเวอร์/ข้อมูล ไม่ใช่ที่ HTTP
การจัดการข้อผิดพลาด แตกต่างกัน — แม้จะมี 200 OK ก็ยังอาจมีอาร์เรย์ errors อยู่ได้

ข้อผิดพลาด: 200 พร้อมอาร์เรย์ข้อผิดพลาด

GraphQL แตกต่างจากรหัสสถานะของ REST โดยทั่วไปจะส่ง HTTP 200 และรายงานความล้มเหลวบางส่วนไว้ภายในเนื้อหาการตอบกลับ data อาจมีข้อมูลเพียงบางส่วน ขณะที่ errors จะแสดงรายการสิ่งที่ล้มเหลว ไคลเอ็นต์ของคุณจึงต้องตรวจสอบทั้งสองส่วน

{
  "data": { "user": null },
  "errors": [
    {
      "message": "User not found",
      "path": ["user"],
      "extensions": { "code": "NOT_FOUND" }
    }
  ]
}

หลักเกณฑ์ช่วยตัดสินใจ

หลักง่าย ๆ ที่ใช้ได้จริงมีดังนี้:

API สาธารณะซึ่งพึ่งพาการแคชสูงและใช้ CRUD กับทรัพยากร → REST
API ภายใน/ผลิตภัณฑ์ที่ป้อนข้อมูลให้ไคลเอ็นต์หลากหลายและมีความสามารถสูงผ่านข้อมูลที่เชื่อมโยงกัน → GraphQL
แบ็กเอนด์หลายตัวที่ต้องรวมไว้เบื้องหลังสัญญาซึ่งระบุชนิดข้อมูลเดียวกัน → เกตเวย์ GraphQL

การใช้ทั้งสองแบบร่วมกันเป็นเรื่องปกติและเหมาะสม: ใช้ REST สำหรับเว็บฮุก/การอัปโหลด และใช้ GraphQL สำหรับกราฟข้อมูลที่แอปใช้เรียกอ่าน

การให้บริการ GraphQL ผ่าน HTTP ใน PHP

ในทางปฏิบัติ จุดปลายทาง GraphQL ใน PHP คือเส้นทางเดียวที่อ่านเนื้อหา JSON ดึง query และ variables ออกมา ดำเนินการกับ schema แล้วส่งคืน { data, errors } เมื่อเทียบกับเส้นทางจำนวนมากของ REST ชั้นการส่งข้อมูลจึงมีรูปแบบเดียวกัน ความแตกต่างทั้งหมดอยู่ในสตริงคิวรีที่ไคลเอ็นต์ส่งมา

<?php
// Minimal GraphQL-over-HTTP entry point
$input = json_decode(file_get_contents('php://input'), true) ?? [];
$query = $input['query'] ?? '';
$variables = $input['variables'] ?? null;

// $result = GraphQL::executeQuery($schema, $query, null, $ctx, $variables);
// header('Content-Type: application/json');
// echo json_encode($result->toArray());
var_dump(['query' => $query, 'variables' => $variables]);

ตรวจสอบความเข้าใจ

ในกรณีใดที่ REST ยังคงมีข้อได้เปรียบเหนือ GraphQL อย่างชัดเจน

ทบทวน

คุณได้เปรียบเทียบ GraphQL กับ REST ในประเด็นสำคัญดังนี้:

GraphQL แก้ปัญหาการดึงข้อมูลมากหรือน้อยเกินไปด้วยจุดปลายทางเดียวที่ระบุชนิดข้อมูล และให้ไคลเอ็นต์เป็นผู้เลือกข้อมูล
GraphQL เหมาะอย่างยิ่งเมื่อมีไคลเอ็นต์หลายประเภท มีข้อมูลเป็นรูปกราฟ และต้องรวมข้อมูลจากแบ็กเอนด์
REST ยังคงแข็งแกร่งสำหรับ API สาธารณะที่แคชได้ การทำ CRUD แบบง่าย การอัปโหลด และผู้ใช้ตามแบบแผนทั่วไป
GraphQL ย้ายต้นทุนไปไว้ที่เซิร์ฟเวอร์ ได้แก่ N+1 ข้อจำกัดต้นทุนคิวรี การแคช และความหมายแบบ 200 พร้อมข้อผิดพลาด

ถัดไป: การสร้าง schema ด้วย webonyx/graphql-php จริง

คำถามที่พบบ่อย

บทเรียน “GraphQL เทียบกับ REST” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “GraphQL เทียบกับ REST” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส PHP Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส PHP Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “GraphQL เทียบกับ REST”

ทำความเข้าใจว่าเมื่อใด GraphQL เหนือกว่า REST และเพราะเหตุใด คุณปฏิบัติ PHP Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน PHP Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน PHP Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “GraphQL เทียบกับ REST” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน PHP Academy นี้ได้ไหม

ได้ บทเรียน PHP Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ PHP Academy