ว่าด้วยเรื่องของ REST กับ GraphQL

เก็บตกจากการไปฟังเรื่อง GraphQL จากงาน CNX Meetup ที่เชียงใหม่ พบว่ามีหลายสิ่งอย่างที่น่าสนใจ พบว่ามีหลายสิ่งอย่างที่ชวนสงสัย หนึ่งในนั้นคือ GraphQL vs. REST ว่ามันเหมือนหรือแตกต่างกันอย่างไร ดังนั้น จึงทำการสรุปแบบกว้าง ๆ ไว้นิดหน่อย

เริ่มต้นกับ GraphQL

เป็นแนวคิดใหม่ ๆ ของการพัฒนาระบบ APIs ให้สะดวกมากยิ่งขึ้น แทนที่จะกำหนด Endpoint มากมายขึ้นมาตาม resources ก็ให้มีเพียง Endpoint เดียว จากนั้นก็ส่ง query เข้าไปเพื่อใช้งาน ส่งผลให้ทีม frontend และ backend ทำงานด้วยกันและใกล้ชิดกันมากขึ้น แต่ก็ยังทำการส่งและรับข้อมูลอยู่บน HTTP protocol เช่นเดิม รวมทั้งยังใช้แนวความคิดต่าง ๆ จาก REST อยู่

มาดูเรื่องแรกคือ Resources

หัวใจหลักของ REST คือ resource โดยแต่ละ resource จะมี endpoint แยกตาม HTTP method ตัวอย่างเช่น การเข้าถึง resource ชื่อว่า employee ด้วย HTTP GET จะส่งข้อมูลของ employee ในรูปแบบ JSON กลับมา ซึ่งข้อมูลประกอบไปด้วย

• รายละเอียดของ employee
• รายละเอียดของ department ที่อยู่

ดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="1.txt"] ทุก ๆ ครั้งที่เรียกใช้งานผ่าน Endpoint ของ resource employee จะทำการส่งข้อมูลในรูปแบบนี้กลับมาเสมอ แต่ GraphQL มีข้อแตกต่างออกไป คือ จะทำการกำหนดชนิดของข้อมูลออกเป็น 2 ส่วน (เช่นเดียวกับ REST) ซึ่งมีความสัมพันธ์ตามที่กำหนด มันก็คือการกำหนด resource นั่นเอง จากตัวอย่างกำหนดแบบ 2 ทิศทางคือ 1. แต่ละ Employee จะมีข้อมูล Department 2. แต่ละ department จะมี list ของ employee [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="2.txt"] จากนั้น resource หรือ endpoint นี้ของ GraphQL สามารถทำการกำหนดรูปแบบของการ query หรือดึงข้อมูลตามที่ client หรือผู้ใช้งานต้องการได้ ซึ่งเป็นข้อแตกต่างจาก REST !! ที่ข้อมูลจะถูกระบุไว้อยู่แล้ว (เพิ่มหรือลดไม่ได้) สามารถทำการกำหนดการ query ด้วย GraphQL Schema ดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="3.txt"] ดังนั้นผู้ใช้งานสามารถส่ง query เข้ามายัง GraphQL ได้ตามที่ต้องการ ยกตัวอย่างเช่น การดึงข้อมูลของ employee ที่มี id=1 ต้องการข้อมูลในรูปแบบที่แตกต่างกันดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="4.txt"] มาถึงตรงนี้น่าจะพอทำให้เก็นความแตกต่างเล็กน้อย แต่ว่ามีประโยชน์มาก ๆ สำหรับผู้เรียกใช้งานแล้วนะ เช่น ลดจำนวน Endpoint ของ APIs ลงไป ลดขนาดข้อมูลของ response ลงไปได้เยอะ ปรับเปลี่ยนรูปแบบข้อมูลตามความต้องการของผู้ใช้งาน

ปล. เห็นนรกของฝั่งที่พัฒนา APIs ด้วย GraphQL กันบ้างไหม ?

มาดูเรื่องที่สองคือ URL Endpoint หรือ Routing

ในส่วนของ REST นั้นจะมีการกำหนด URL Endpoint ไว้ในรูปแบบดังนี้ GET /employee/:id POST /employee/:id PUT /employee/:id GET /department/:id ซึ่งแยกตาม resource และ HTTP Method กัน แต่สิ่งที่ยากขึ้นมานิดหน่อย คือ จะเรียกใช้งานอย่างไร แน่นอนว่า REST APIs เหล่านี้ก็ต้องมีเอกสารอธิบายการใช้งาน รวมทั้งรูปแบบของ request และ response อีกด้วย ใน GraphQL นั้นไม่ได้ใช้ URL Endpoint เหมือนกับ REST แต่ใช้สิ่งที่เรียกว่า GraphQL Schema ซึ่งทำการกำหนดผ่าน type 2 ชนิดคือ

1. Query สำหรับการดึงข้อมูล
2. Mutation สำหรับการเพิ่มและแก้ไขข้อมูล

ยกตัวอย่างดังนี้ [gist id="b68e938aa9e85fdeb5e267cf5af10a2a" file="5.txt"] โดยใน request เดียวสามารถส่งการ query ได้มากกว่าและซับซ้อนได้ หรือจะทำการเพิ่มหรือแก้ไขข้อมูลก็ได้ ซึ่งลดจำนวนการเรียกใช้งาน APIs ลงไป แถมไม่ต้องไประบุด้วยอีกว่าต้องใช้ HTTP GET, POST, PUT หรือ DELETE เนื่องจากได้เปลี่ยนวิธีการด้วยการส่ง keyword ใหม่ไปนั่นเอง [code] query { … } mutation{ ... } [/code] มองง่าย ๆ คือ GraphQL นั้นคือ endpoint ที่ทำการเรียกหลาย ๆ Endpoint ของ REST นั่นเอง เป็นข้อดีอย่างมากของ GraphQL แสดงดังรูป รูปมันคุ้น ๆ เหมือนกับ API Gateway ยังไงก็ไม่รู้นะ !!

โดยสรุปแล้ว

REST และ GraphQL นั้นไม่ได้แตกต่างกันมากนัก มีพื้นฐานมาจากเรื่องที่คล้ายหรือใกล้เคียงกัน แต่สิ่งที่แตกต่างเพียงเล็กน้อยของ GraphQL นั้น กลับช่วยทำให้เกิดความเปลี่ยนแปลงในการสร้างและใช้งาน APIs มากมาย GraphQL นั้นช่วยลดจำนวน APIs endpoint ลงไป ช่วยทำให้ผู้ใช้งานสะดวกยิ่งขึ้น ช่วยลดข้อมูลที่ไม่จำเป็นลงไปได้ ตามความต้องการของผู้ใช้งาน แต่ก็ได้เพิ่มเรื่องของการ query ที่ซับซ้อนขึ้นมา ถ้าระบบ APIs ของเราเป็น REST อยู่แล้ว มันก็ง่ายมาก ๆ สำหรับการปรับเปลี่ยนหรือเพิ่ม GraphQL ขึ้นมา ปล. น่าจะพอเห็นว่าการพัฒนา APIs ด้วย GraphQL มันน่าสนุกเพียงใด ถ้าทีม frontend และ backend ไม่คุยกัน หรือ ทำงานด้วยกัน ผมเชื่อว่า นรกกินหัวแน่นอนครับ ขอให้สนุกกับการ coding ครับ Reference Websites https://dev-blog.apollodata.com/introducing-explore-graphql-e71e5fda4e1a https://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b https://dev-blog.apollodata.com/why-graphql-is-the-future-3bec28193807 https://medium.com/@scbarrus/graphql-is-the-king-long-live-the-king-r-i-p-rest-cf04ce38f6c