การใช้ Namespace ใน Schema เพื่อหลีกเลี่ยงความขัดแย้ง

นักพัฒนาที่เผยแพร่ปลั๊กอินใน WordPress directory ไม่สามารถรู้ล่วงหน้าว่าใครจะใช้ปลั๊กอินของตน หรือไซต์จะมีการตั้งค่า/สภาพแวดล้อมอย่างไร รวมถึงปลั๊กอินอื่นใดที่อาจถูกติดตั้ง ด้วยเหตุนี้ ปลั๊กอินจึงต้องเตรียมพร้อมสำหรับความขัดแย้งและพยายามป้องกันไว้ล่วงหน้า

หนึ่งในวิธีที่ WordPress plugin ใช้หลีกเลี่ยงความขัดแย้งคือการใช้ PHP namespacing Namespace ถูกใช้กันอย่างแพร่หลายในชุมชน PHP โดยปฏิบัติตาม PHP Standard Recommendation PSR-4 เพื่อเปิดใช้งาน Composer autoloading แพ็กเกจ PHP ต้องประกอบด้วยชื่อ vendor ในรูปแบบ "vendor-name/package-name" และ namespace ที่สอดคล้องกันจะปรากฏในโค้ด PHP:

<?php
namespace VendorName\PackageName\ClassName;

Namespacing มีความหมายในบริบทของ GraphQL เช่นกัน เพื่อหลีกเลี่ยงความขัดแย้งที่อาจเกิดขึ้นบน schema ดังต่อไปนี้:

มี type สองรายการที่มีชื่อเดียวกัน
มี field สองรายการบน type เดียวกันที่มีชื่อเดียวกัน
มี directive สองรายการที่มีชื่อเดียวกัน

Namespacing ได้รับการ ร้องขอสำหรับ GraphQL spec:

At the moment all GraphQL types share one global namespace. This is also true for all of the fields in mutation/subscription type. It can be a concern for bigger projects which may contain several loosely-coupled parts in a GraphQL schema.

อย่างไรก็ตาม Lee Byron (หนึ่งในผู้สร้าง GraphQL ขณะทำงานที่ Facebook) เชื่อว่าการเพิ่ม namespacing ใน spec ไม่มีความจำเป็น ใน ความคิดเห็นนี้ เขาอธิบายว่า Facebook จัดการ type หลายพันรายการใน GraphQL schema โดยไม่มีความขัดแย้งได้อย่างไร:

We avoid naming collisions in two ways:

integration tests.

We don't allow any commit to merge into our repository that would result in a broken GraphQL schema. [...]

Common naming patterns.

We have common patterns for naming things which naturally avoid collision problems. [...]

แต่การที่กลยุทธ์นี้ใช้ได้ผลกับ Facebook ไม่ได้หมายความว่าจะใช้ได้ผลกับ WordPress เช่นกัน เนื่องจาก Facebook ควบคุม input ทั้งหมดใน GraphQL schema จึงสามารถปฏิบัติตามขั้นตอนในการตั้งชื่อ entity เพื่อให้แน่ใจว่าจะไม่เกิดความขัดแย้ง แต่ไซต์ WordPress พึ่งพาปลั๊กอินของบุคคลที่สามอย่างมาก และไม่สามารถควบคุมวิธีที่ปลั๊กอินเหล่านั้นถูกสร้างขึ้น

ตัวอย่างเช่น หากไซต์ใช้ปลั๊กอิน WooCommerce และ Easy Digital Downloads พร้อมกัน และทั้งคู่มี type ชื่อ Product ใน GraphQL schema จะเกิดความขัดแย้ง ทางเลือกเดียวสำหรับเจ้าของไซต์คือติดต่อบริษัทใดบริษัทหนึ่งและขอให้แก้ไขโค้ด นี่ไม่ใช่การป้องกัน แต่เป็นการแก้ไขภายหลัง และไม่มีความน่าเชื่อถือ

Namespacing จึงช่วยให้เจ้าของไซต์ WordPress มั่นใจได้ว่าโค้ดของตนจะทำงานได้เสมอ หาก type สองรายการมีชื่อ Product ผู้ดูแลระบบไซต์สามารถเปิดใช้งาน namespacing ใน GraphQL schema และ type เหล่านี้จะถูกเปลี่ยนชื่อโดยอัตโนมัติเป็น WooCommerce_Product และ EDD_Product เพื่อหลีกเลี่ยงความขัดแย้ง

ประโยชน์เพิ่มเติมคือ namespacing ทำให้ GraphQL schema มีความสวยงามมากขึ้น หาก WooCommerce ต้องการให้แน่ใจว่าจะไม่มีความขัดแย้งเกิดขึ้นกับปลั๊กอินของตน จะต้อง "ใส่ namespace" ใน type name เอง ได้แก่ WCProduct, WCDownload และ WCPayment (หรือเพื่อให้แน่ใจอย่างสมบูรณ์ว่าจะทำงานได้เสมอ อาจใช้ชื่อว่า WooCommerceProduct, WooCommerceDownload และ WooCommercePayment) ด้วย namespacing type เหล่านี้สามารถใช้ชื่อที่เป็นธรรมชาติมากขึ้นอย่าง Product, Download และ Payment