Namespacing schematu w celu uniknięcia konfliktów

Deweloperzy publikujący wtyczki w katalogu WordPressa nie wiedzą z góry, kto będzie ich używał ani jaką konfigurację/środowisko będzie miała witryna, w tym jakie inne wtyczki mogą być zainstalowane. W związku z tym wtyczka musi być przygotowana na konflikty i starać się im zapobiegać z wyprzedzeniem.

Jednym ze sposobów, w jaki wtyczki WordPress unikają konfliktów, jest namespacing PHP. Przestrzenie nazw są powszechnie stosowane w społeczności PHP zgodnie z zaleceniem standardowym PSR-4, umożliwiającym autoloading Composera. Pakiety PHP muszą zawierać nazwę dostawcy w formie "vendor-name/package-name", a odpowiednia przestrzeń nazw jest obecna w kodzie PHP:

<?php
namespace VendorName\PackageName\ClassName;

Namespacing może mieć sens również w kontekście GraphQL, aby uniknąć następujących potencjalnych konfliktów w schemacie:

Posiadanie dwóch typów o tej samej nazwie
Posiadanie dwóch pól tego samego typu o tej samej nazwie
Posiadanie dwóch dyrektyw o tej samej nazwie

Namespacing był postulowany dla specyfikacji GraphQL:

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.

Jednak Lee Byron (jeden z twórców GraphQL podczas pracy w Facebooku) uważa, że dodanie namespacingu do specyfikacji nie jest uzasadnione. W tym komentarzu wyjaśnia, jak Facebook zarządza tysiącami typów w swoim schemacie GraphQL bez konfliktów:

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. [...]

Jednak fakt, że ta strategia sprawdza się w przypadku Facebooka, nie oznacza, że zadziała w WordPressie: ponieważ Facebook kontroluje wszystkie dane wejściowe swojego schematu GraphQL, może sobie pozwolić na stosowanie procedury nazewnictwa encji, dzięki czemu żaden konflikt nie powstanie. Witryna WordPress w dużym stopniu opiera się natomiast na wtyczkach firm trzecich i nie kontroluje sposobu ich tworzenia.

Na przykład, jeśli witryna korzysta z wtyczek WooCommerce i Easy Digital Downloads, a obie mają typ o nazwie Product dla schematu GraphQL, dojdzie do konfliktu. Jedynym wyjściem dla właściciela witryny jest skontaktowanie się z jedną z firm i poproszenie o modyfikację kodu. To nie jest zapobieganie, lecz korekta, i jest zawodne.

Namespacing może zatem dać właścicielom witryn WordPress pewność, że ich kod będzie zawsze działał. Jeśli dwa typy mają nazwę Product, administrator witryny może włączyć namespacing w schemacie GraphQL, a typy te zostaną automatycznie przemianowane na WooCommerce_Product i EDD_Product, co pozwoli uniknąć konfliktu.

Dodatkową korzyścią jest to, że namespacing sprawia, iż schemat GraphQL staje się bardziej elegancki: gdyby WooCommerce chciał mieć pewność, że żaden konflikt z jego wtyczką nigdy nie wystąpi, musiałby „namespacować" swoje typy w samej nazwie typu: WCProduct, WCDownload i WCPayment (lub, dla całkowitej pewności działania, mógłby je nazwać WooCommerceProduct, WooCommerceDownload i WooCommercePayment). Dzięki namespacingowi typy te mogą nosić bardziej naturalne nazwy Product, Download i Payment.