กรณีการใช้งานสำหรับ custom endpoint หลายรายการ
GraphQL มักจะเปิดเผย endpoint เดียวสำหรับการ query ข้อมูล อย่างไรก็ตาม มีบางสถานการณ์ที่การเปิดเผย custom endpoint หลายรายการจะเหมาะสมกว่า โดยแต่ละ endpoint นำเสนอ schema ที่ปรับแต่งเอง วิธีนี้ช่วยให้เราสามารถให้พฤติกรรมที่แตกต่างกันแก่ผู้ใช้หรือแอปพลิเคชันต่างๆ เพียงแค่เปลี่ยน endpoint ที่เข้าถึง
การเปิดเผย endpoint หลายรายการใน GraphQL ไม่ได้เทียบเท่ากับ REST ใน REST แต่ละ endpoint ให้การเข้าถึง resource หรือชุด resource ที่กำหนดไว้ล่วงหน้า แต่ endpoint หลายรายการของ GraphQL แต่ละรายการยังคงให้การเข้าถึงข้อมูลทั้งหมดจาก schema ของตน ทำให้สามารถดึงข้อมูลเฉพาะที่ต้องการได้ นี่ยังคงเป็นพฤติกรรม GraphQL ปกติ แต่เพิ่มความสามารถในการเข้าถึงข้อมูลจาก schema ที่แตกต่างกัน
ความสามารถนี้แตกต่างจาก schema stitching หรือ federation ซึ่งช่วยให้รวมแหล่งข้อมูลหลายแหล่งเข้าเป็น graph เดียวที่รวมเป็นหนึ่ง การใช้ endpoint หลายรายการหมายถึงการจัดการกับหลาย schema โดยมีเจตนาที่จะดูแลแต่ละ schema อย่างเป็นอิสระ ไม่ใช่เป็นส่วนหนึ่งของ schema ที่ใหญ่กว่า
การเปิดเผย schema ที่แตกต่างกันสามารถให้การเข้าถึง graph อิสระหลายรายการ ผู้สร้าง GraphQL อย่าง Lee Byron อธิบายว่าสิ่งนี้มีประโยชน์เมื่อใด:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
มาสำรวจกรณีการใช้งานเพิ่มเติมที่การเปิดเผย GraphQL endpoint หลายรายการมีความเหมาะสม
เปิดเผย endpoint สำหรับ admin และสาธารณะแยกกัน
เมื่อเราใช้ graph เดียวสำหรับข้อมูลทั้งหมดในบริษัท เราสามารถตรวจสอบว่าใครมีสิทธิ์เข้าถึงฟิลด์ต่างๆ ใน GraphQL schema ของเราได้โดยการตั้งค่านโยบายการควบคุมการเข้าถึง ตัวอย่างเช่น เราสามารถกำหนดค่าให้ฟิลด์เข้าถึงได้เฉพาะผู้ใช้ที่เข้าสู่ระบบหรือผู้ใช้ที่มี role เฉพาะ
อย่างไรก็ตาม เมื่อมีฟิลด์ที่มีข้อมูลละเอียดอ่อนหรือเป็นความลับ ซึ่งไม่ควรเข้าถึงได้โดยผู้ที่ไม่ได้รับอนุญาตในทุกกรณี เราควรไม่เปิดเผยฟิลด์เหล่านี้ใน schema สาธารณะตั้งแต่แรก และเปิดเผยเฉพาะใน schema ส่วนตัวที่ทีมงานเท่านั้นที่เข้าถึงได้ กลยุทธ์นี้จะปกป้องข้อมูลส่วนตัวของเราจากปัญหาที่ไม่ได้ตั้งใจ เช่น บัคในซอฟต์แวร์และความประมาทในการกำหนดค่า schema และยังเพิ่มความปลอดภัยโดยอนุญาตเฉพาะผู้เยี่ยมชมจาก IP บางรายการให้เข้าถึง endpoint ส่วนตัว
ดังนั้น เราสามารถสร้าง schema แยกกันสองรายการ ได้แก่ Admin schema และ Public schema และเปิดเผยภายใต้ endpoint /graphql/admin (และจำกัดการเข้าถึงเฉพาะผู้เยี่ยมชมจาก IP บางรายการ) และ /graphql/public (เข้าถึงได้โดยทุกคน) ตามลำดับ
จำกัดการเข้าถึงข้อมูลส่วนตัวในวิธีที่ปลอดภัยยิ่งขึ้น
ส่วนนี้เป็นการขยายความจากส่วนก่อนหน้า: ไม่ใช่แค่สาธารณะ vs admin แต่รวมถึงสถานการณ์ใดก็ตามที่กลุ่มผู้ใช้หนึ่งต้องไม่สามารถเข้าถึงข้อมูลของกลุ่มผู้ใช้อื่นได้อย่างแน่นอน
ตัวอย่างเช่น เมื่อเราต้องการสร้าง schema ที่ปรับแต่งสำหรับลูกค้าต่างๆ เราสามารถเปิดเผย custom endpoint สำหรับแต่ละราย (/graphql/some-client, /graphql/another-client เป็นต้น) ซึ่งอาจปลอดภัยกว่าการให้สิทธิ์เข้าถึง schema รวมเดียวกันและตรวจสอบผ่านการควบคุมการเข้าถึง
ให้พฤติกรรมที่แตกต่างกันแก่แอปพลิเคชันต่างๆ
เราสามารถมอบพฤติกรรมที่แตกต่างกันแก่แอปพลิเคชันต่างๆ ที่เข้าถึงแหล่งข้อมูลเดียวกัน
ตัวอย่างเช่น Reddit ให้การตอบสนองที่แตกต่างกันหากเข้าถึงจากเบราว์เซอร์บนเดสก์ท็อปหรือจากเบราว์เซอร์บนมือถือ จากเบราว์เซอร์บนเดสก์ท็อป ไม่ว่าเราจะเข้าสู่ระบบหรือไม่ก็ตาม เราสามารถดูเนื้อหาได้โดยตรง:
อย่างไรก็ตาม เมื่อเข้าถึงจากมือถือ เราต้องเข้าสู่ระบบก่อนจึงจะเข้าถึงเนื้อหาได้ และได้รับการแนะนำให้ใช้แอปแทน:
พฤติกรรมที่แตกต่างกันนี้สามารถทำได้โดยการสร้าง schema สองรายการ ได้แก่ Desktop schema และ Mobile schema และเปิดเผยภายใต้ /graphql/desktop และ /graphql/mobile ตามลำดับ
สร้างเว็บไซต์ในหลายภาษา
หากเราต้องการสร้างเว็บไซต์เดียวกันในหลายภาษา เราสามารถให้รหัสภาษาเป็นส่วนหนึ่งของโครงสร้าง custom endpoint เช่น /graphql/en สำหรับภาษาอังกฤษ และ /graphql/fr สำหรับภาษาฝรั่งเศส จากนั้น GraphQL server สามารถดึงข้อมูลนี้และแปลข้อมูลเป็นภาษาที่ต้องการ
สุดท้าย เราชี้ไปยัง endpoint แต่ละรายการใน static site generator เพื่อสร้างเว็บไซต์ในภาษาใดภาษาหนึ่ง:
ทดสอบ schema ที่อัปเกรดก่อนปล่อยสู่ production
หากเราต้องการอัปเกรด GraphQL schema และให้ผู้ใช้บางกลุ่มทดสอบล่วงหน้า เราสามารถเปิดเผย schema ใหม่นี้ผ่าน endpoint /graphql/upcoming ยิ่งกว่านั้น เราอาจเปิดเผย endpoint /graphql/bleeding-edge ที่ deploy schema จาก DEV อย่างต่อเนื่องด้วย
รองรับแนวทาง BfF
Backend-for-Frontends (หรือเรียกสั้นๆ ว่า BfF) คือแนวทางในการสร้าง API ที่แตกต่างกันสำหรับ client ที่แตกต่างกัน โดยแต่ละ client "เป็นเจ้าของ" API ของตน ทำให้สามารถสร้างเวอร์ชันที่เหมาะสมที่สุดตามความต้องการของตัวเอง
ในโมเดลนี้ BfF ที่ปรับแต่งเองทำหน้าที่เป็นตัวกลางระหว่าง back-end services และ client:
โมเดลนี้สามารถทำได้ใน GraphQL โดยการ implement BfF ทั้งหมดใน GraphQL server เดียวที่มี endpoint หลายรายการ โดยแต่ละ endpoint รับผิดชอบ BfF/client เฉพาะ (เช่น /graphql/mobile และ /graphql/web):
