Namespacing do schema para evitar conflitos

Os desenvolvedores que publicam plugins no diretório do WordPress não sabem antecipadamente quem usará seus plugins, nem qual configuração/ambiente o site terá, incluindo quais outros plugins poderão estar instalados. Por isso, o plugin deve estar preparado para conflitos e tentar evitá-los preventivamente.

Uma das formas que os plugins WordPress utilizam para evitar conflitos é por meio do namespacing PHP. Os namespaces são amplamente utilizados na comunidade PHP, seguindo a recomendação padrão PSR-4 para habilitar o autoloading do Composer. Os pacotes PHP devem incluir o nome do fornecedor, como "vendor-name/package-name", e o namespace correspondente está presente no código PHP:

<?php
namespace VendorName\PackageName\ClassName;

O namespacing também pode fazer sentido no contexto do GraphQL, para evitar os seguintes conflitos potenciais que podem ocorrer no schema:

Ter dois tipos com o mesmo nome
Ter dois campos no mesmo tipo com o mesmo nome
Ter duas directives com o mesmo nome

O namespacing foi solicitado para a especificação do 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.

No entanto, Lee Byron (um dos criadores do GraphQL enquanto trabalhava no Facebook) acredita que adicionar namespacing à especificação não se justifica. Neste comentário, ele explica como o Facebook gerencia os milhares de tipos em seu schema GraphQL sem conflitos:

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

Mas o fato de essa estratégia funcionar para o Facebook não significa que funcionará no WordPress: como o Facebook controla todos os inputs do seu schema GraphQL, pode se dar ao luxo de seguir um procedimento para nomear as entidades, garantindo que nenhum conflito surja. Já um site WordPress depende fortemente de plugins de terceiros e não controla como esses plugins são produzidos.

Por exemplo, se um site usa os plugins WooCommerce e Easy Digital Downloads, e ambos têm um tipo chamado Product para o schema GraphQL, haverá um conflito. O único recurso para o dono do site é entrar em contato com uma das empresas e pedir que modifique seu código. Isso não é prevenção, mas correção, e é pouco confiável.

O namespacing pode então oferecer aos donos de sites WordPress a tranquilidade de que seu código sempre funcionará. Se dois tipos têm o nome Product, o administrador do site pode habilitar o namespacing no schema GraphQL, e esses tipos serão automaticamente renomeados para WooCommerce_Product e EDD_Product, evitando o conflito.

Como benefício adicional, o namespacing torna o schema GraphQL mais elegante: se o WooCommerce quisesse garantir que nunca surgisse nenhum conflito com seu plugin, teria que "namespacear" seus tipos no próprio nome do tipo: WCProduct, WCDownload e WCPayment (ou, para ter absoluta certeza de que sempre funcionará, poderia chamá-los de WooCommerceProduct, WooCommerceDownload e WooCommercePayment). Graças ao namespacing, esses tipos podem ter os nomes mais naturais Product, Download e Payment.