Namespacing do schema

Faça com que todos os tipos e interfaces adicionados ao schema pelos plugins recebam automaticamente um namespace.

O namespacing do schema evita conflitos de nomes, que ocorrem quando diferentes proprietários (ex.: times diferentes na empresa, ou entre plugins de terceiros) usam o mesmo nome para um tipo ou interface.

Por exemplo, suponha que a empresa "AwesomeWP" tenha o time de Tutoriais e o time de Vendas, e que ambos criem um tipo Product para o schema GraphQL da empresa, gerando um conflito.

Aplicando o namespacing ao schema, os dois tipos seriam automaticamente convertidos em AwesomeWPTutorialsProduct e AwesomeWPSalesProduct, evitando o conflito sem precisar modificar o schema manualmente nem fazer com que os times interajam entre si.

​

As entidades do modelo de dados do WordPress não recebem namespace

O modelo de dados do WordPress é considerado canônico, e seus tipos de schema GraphQL (como Post e User) e interfaces (como Commentable e WithMeta) não recebem namespace.

​

Namespacing do schema nos endpoints

Há 2 níveis nos quais podemos definir se o schema receberá namespace ou não. Em ordem de prioridade:

​

1. Na configuração do schema

O namespacing do schema para um custom endpoint ou persisted query pode ser definido por meio da configuração de schema correspondente:

​

2. Modo padrão, definido nas Configurações

Se a configuração do schema tiver o valor "Default", o modo definido nas Configurações será utilizado:

​

Visualizando o schema com namespace

Use o cliente Voyager para visualizar o schema com namespace.

Quando o namespacing está desabilitado, o schema do WordPress tem esta aparência:

Quando está habilitado, os tipos e interfaces adicionados pelos plugins recebem namespace e ficam assim:

​

Consultando nomes de tipos (sem) namespace

Uma vez habilitado o namespacing, os tipos podem ser consultados usando tanto o nome com namespace quanto o nome sem namespace. Portanto, apenas as queries que envolvem tipos conflitantes precisam ser editadas, não todas elas.

Por exemplo, se o time de Vendas da AwesomeWP também tiver um tipo Discount, uma query que solicita esse nome de tipo ainda funciona:

query {
  discounts {
    ...DiscountProps
  }
}
 
fragment DiscountProps on Discount {
  price
  dateRange
}Copy

Apenas o tipo conflitante Product deve ser atualizado para AwesomeWPSalesProduct na query, de modo a remover qualquer ambiguidade:

query {
  products {
    ...ProductProps
  }
}
 
fragment ProductProps on AwesomeWPSalesProduct {
  price
  dateRange
}Copy

​

Especificação GraphQL

Esta funcionalidade atualmente não faz parte da especificação GraphQL, mas foi solicitada em:

• Issue #163 - Namespaces.