GraphQL เทียบกับ REST API

คุณเคยทำงานในโครงการพัฒนาแอปเว็บมาก่อนหรือไม่? ถ้าเคย คุณอาจเคยได้ยินคำว่า "GraphQL" แต่อันที่จริงแล้วมันหมายถึงอะไร? ใช้ในฝั่งเซิร์ฟเวอร์หรือฝั่งไคลเอนต์? และเมื่อไหร่การบูรณาการ GraphQL จะเหมาะสมกว่าอย่างอื่น? ในบทความนี้ เราจะนำคุณผ่านคำถามเหล่านี้

ในฐานะที่เป็นช่องทางสื่อสารสำหรับการถ่ายโอนข้อมูลระหว่างส่วนประกอบซอฟต์แวร์ผ่านอินเทอร์เน็ต APIs มีบทบาทสำคัญในสถาปัตยกรรมบริการเว็บสมัยใหม่ ทำหน้าที่เหมือนออกซิเจน เทคโนโลยี API เช่น SOAP (โปรโตคอลการส่งข้อความบริการเว็บ) REST (รูปแบบสถาปัตยกรรม) และ GraphQL (ภาษาสอบถามและเครื่องมือ) ช่วยอำนวยความสะดวกในการพัฒนาซอฟต์แวร์โดยสนับสนุนการบูรณาการและการแลกเปลี่ยนข้อมูลระหว่างบริการต่าง ๆ ทำให้การพัฒนาสะดวกและยืดหยุ่นยิ่งขึ้น

แม้ว่าจะมี API ประเภทต่าง ๆ มากมาย แต่ในช่วงไม่กี่ปีที่ผ่านมา การถกเถียงส่วนใหญ่เกี่ยวกับสองแนวทางหลัก: REST (การโอนสถานะเชิงแทน) และ GraphQL ทั้งคู่มีข้อดีที่หลากหลายและถูกใช้งานทั่วโลกในโครงการเว็บ อย่างไรก็ตาม พวกเขาแตกต่างกันอย่างมากในการจัดการการสื่อสารข้อมูล

REST API คืออะไร?#

REST คือรูปแบบสถาปัตยกรรมที่มีโครงสร้างพัฒนาขึ้นในต้นศตวรรษที่ 21 สำหรับการสร้างแอปพลิเคชันไฮเปอร์มีเดียข้ามเครือข่าย ออกแบบมาเพื่อใช้ในโปรโตคอลการสื่อสารที่ไม่มีสถานะและแคชได้ระหว่างไคลเอนต์และเซิร์ฟเวอร์ REST API (หรือที่รู้จักในชื่อ RESTful API) เป็นเครื่องมือขับเคลื่อนของสถาปัตยกรรม REST

REST API ใช้ตัวระบุทรัพยากรสากล (URIs) เพื่อระบุทรัพยากร REST API ทำงานโดยใช้จุดเชื่อมต่อที่แตกต่างกันเพื่อดำเนินการ CRUD (สร้าง อ่าน อัปเดต และลบ) บนทรัพยากรเครือข่าย มันพึ่งพารูปแบบข้อมูลที่กำหนดไว้ล่วงหน้า (หรือที่รู้จักในชื่อประเภทสื่อ หรือประเภท MIME) เพื่อตัดสินใจเกี่ยวกับรูปแบบและขนาดของทรัพยากรที่ส่งให้กับไคลเอนต์ รูปแบบที่พบได้บ่อยคือ JSON และ XML (บางครั้ง HTML หรือข้อความธรรมดา)

หลังจากที่ไคลเอนต์ร้องขอทรัพยากร เซิร์ฟเวอร์จะประมวลผลคำขอและส่งคืนข้อมูลทั้งหมดที่เกี่ยวข้องกับทรัพยากรนั้น การตอบกลับจะประกอบด้วยรหัสตอบกลับ HTTP เช่น "200 OK" (สำหรับคำขอ REST ที่สำเร็จ) และ "404 Not Found" (สำหรับทรัพยากรที่ไม่มีอยู่)

REST API ทำงานอย่างไร?#

REST APIs พึ่งพาจุดสิ้นสุดที่กำหนดไว้ล่วงหน้าเพื่อเผยทรัพยากรผ่าน HTTP แต่ละจุดสิ้นสุดแทนทรัพยากร เช่น ผู้ใช้หรือโพสต์ และถูกระบุโดย URL ที่ไม่ซ้ำกัน การดำเนินการ REST ผูกติดกับวิธี HTTP มาตรฐานอย่าง GET, POST, PUT และ DELETE ซึ่งสอดคล้องกับการดึง สร้าง อัปเดต และลบข้อมูล

ยกตัวอย่างเช่น การร้องขอ GET /users ดึงรายการผู้ใช้ทั้งหมด ในขณะที่ GET /users/123 สืบรายละเอียดของผู้ใช้เฉพาะที่ระบุด้วย ID ของพวกเขา ถ้าคุณต้องการเข้าถึงข้อมูลที่เกี่ยวข้อง เช่น องค์กรของผู้ใช้และบทบาทองค์กร คุณจะต้องเรียก GET /users/123/organizations เพิ่มเติม

REST ใช้วิธีการที่มุ่งเน้นทรัพยากร โดยเน้นการเข้าถึงและการจัดการทรัพยากรที่แยกจากกัน

GraphQL คืออะไร?#

GraphQL คือทั้งประเภท API (หรือภาษาสอบถาม) และเครื่องยนต์รันทามสำหรับตอบสนองต่อการสอบถามเหล่านั้น มันเสนอ API ที่ง่ายขึ้นและเหมาะสมเป็นพิเศษสำหรับแอปพลิเคชันบมือถือและการนำสถาปัตยกรรมที่ซับซ้อนที่ต้องการชุดย่อยของข้อมูลเฉพาะไปใช้

ด้วย GraphQL นักพัฒนาสามารถระบุข้อมูลที่พวกเขาต้องการดึงจาก API มันยังอนุญาตให้การดึงข้อมูลเป็นไปตามความต้องการแทนที่จะดึงทุกอย่างในครั้งเดียว ทำให้สามารถเปลี่ยนแปลงได้ทันที และบูรณาการแหล่งข้อมูลของบุคคลที่สามเข้ากับแอปพลิเคชัน

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

GraphQL ทำงานอย่างไร?#

ในทางตรงกันข้าม GraphQL ใช้แนวทางการสอบถาม แทนที่จะใช้จุดสิ้นสุดที่กำหนดไว้ล่วงหน้า GraphQL เผยจุดสิ้นสุดเดียวที่รับการสอบถามที่มีโครงสร้าง ไคลเอนต์ระบุว่าต้องการข้อมูลใดโดยใช้ภาษาสอบถาม

ดังนั้น การนำ GraphQL ไปใช้อย่างสมบูรณ์ต้องมีสองส่วน: schema และ resolvers

GraphQL schema#

Schemas กำหนดประเภทของข้อมูลและเขตข้อมูลที่จะดึงผ่านการสอบถาม GraphQL:

ยกตัวอย่าง สมมติว่าคุณมี schema ตามนี้:

ไคลเอนต์สามารถสอบถามชื่อผู้ใช้อีเมล องค์กร และบทบาทโดยใช้คำถามต่อไปนี้:

คำถามนี้ไม่เพียงแต่ดึงเฉพาะเขตข้อมูลที่ร้องขอ (email และ organizations) แต่ยังดึงข้อมูลที่เกี่ยวข้อง (roles) ในการร้องขอครั้งเดียว

GraphQL resolver#

GraphQL resolver เป็นส่วนสำคัญของเซิร์ฟเวอร์ GraphQL ที่กำหนดวิธีที่จะแสวงหาหรือคำนวณข้อมูลที่ร้องขอโดยไคลเอนต์ใน GraphQL query เมื่อไคลเอนต์ส่งคำถาม แต่ละเขตข้อมูลในคำถามจะถูกจับคู่กับ resolver ซึ่งมีตรรกะสำหรับดึงหรือคำนวณข้อมูลสําหรับเขตข้อมูลนั้น

ในตัวอย่างข้างต้น resolvers สำหรับ schema จะมีลักษณะดังนี้:

มีสองประเภทของ resolvers: root resolvers และ field resolvers

• Root Resolvers: จัดการเขตข้อมูลขั้นต้นใน schema เช่น Query, Mutation และ Subscription
• Field Resolvers: จัดการเขตข้อมูลแต่ละอย่างในประเภท มักจะใช้สำหรับคำถามที่ซ้อนกัน ถ้าไม่มี resolver เฉพาะที่กําหนดสําหรับเขตข้อมูล GraphQL ใช้ resolver เริ่มต้น ซึ่งจะส่งกลับค่าส่งจากวัตถุต้นแบบที่มีชื่อเขตข้อมูลที่ตรงกัน

การดำเนินการ GraphQL#

GraphQL รองรับสามประเภทของการดำเนินการ: queries, mutations และ subscriptions

• Query: ใช้เพื่ออ่านข้อมูล
• Mutation: ใช้เพื่อเขียนข้อมูล รวมถึงการดำเนินการเพื่อเพิ่ม แก้ไข และลบข้อมูล
• Subscription: ใช้เพื่อขอการเชื่อมต่อถาวรสําหรับข้อมูล อนุญาตให้ไคลเอนต์ประกาศประเภทของเหตุการณ์ที่สนใจและข้อมูลที่ควรส่งกลับ

ความแตกต่างระหว่าง GraphQL และ REST APIs#

GraphQL และ REST APIs เป็นเครื่องมือในการแลกเปลี่ยนข้อมูลระหว่างบริการเว็บต่าง ๆ แต่เนื่องจากแนวทางต่าง ๆ ในการแก้ไขปัญหา นี่คือความแตกต่างหลักระหว่างพวกเขา:

การดึงข้อมูล#

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

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

ความยืดหยุ่น#

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

GraphQL ในทางกลับกัน มีความยืดหยุ่นมากกว่าและอนุญาตให้ไคลเอนต์ร้องขอเฉพาะข้อมูลที่พวกเขาต้องการ ความยืดหยุ่นนี้มีประโยชน์อย่างยิ่งเมื่อความต้องการของไคลเอนต์เปลี่ยนแปลงบ่อย ๆ เพราะมันขจัดความจำเป็นในการแก้ไขการบูรณาการ API ฝั่งเซิร์ฟเวอร์ ไคลเอนต์สามารถร้องขอเขตข้อมูลใหม่หรือข้อมูลที่ซ้อนกันโดยไม่จำเป็นต้องเปลี่ยนแปลงเซิร์ฟเวอร์

การแคช#

แม้ว่า GraphQL จะมีประสิทธิภาพและยืดหยุ่นในเรื่องการดึงข้อมูล แต่ก็มีข้อเสียหนึ่งคือการแคช

REST API มีระบบนิเวศน์ที่เติบโตอย่างดี เนื่องจากธรรมชาติที่ไม่มีสถานะและมาตรฐานของมัน มันง่ายที่จะทำการแคชคำตอบทั้งในระดับเซิร์ฟเวอร์และระดับคล้าย ซึ่งสามารถลดจำนวนคำขอที่ทำไปยังเซิร์ฟเวอร์อย่างมากและปรับปรุงประสิทธิภาพ

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

ข้อดีและข้อเสีย#

บทสรุป#

แม้ว่า GraphQL จะได้รับความนิยมอย่างมากในฐานะผู้มาทีหลังในช่วงไม่กี่ปีที่ผ่านมา REST API ยังคงมีความสำคัญอย่างยาวนานเนื่องจากการออกแบบที่อะตอมิกและความเข้มงวด

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