🙅‍♀️ Por que o GraphQL não deveria estar no core do WordPress

Sim, você leu o título corretamente. Mesmo sendo eu mesmo o criador de um servidor GraphQL para WordPress, mudei de opinião sobre se o WordPress deveria ou não ser distribuído com GraphQL.

Até não muito tempo atrás, eu acreditava que o GraphQL deveria estar no core do WordPress. A lógica era que os contribuidores estavam gastando tempo e esforço para implementar funcionalidades na WP REST API (operações em batch) que são nativas ao GraphQL.

No entanto, recentemente aprendi algumas informações novas que me fizeram repensar, e agora acredito que o WordPress não deveria ser distribuído com GraphQL, por causa dos riscos adicionais.

Estes são os meus motivos.

​

1. Não satisfaz a regra 80/20

Historicamente, uma determinada funcionalidade é adicionada ao core do WordPress apenas se satisfizer a regra 80/20, o que significa que 80% ou mais dos usuários a utilizarão.

Seria esse o caso com GraphQL? Acho que a resposta é "não", baseando-me no precedente da introdução da WP REST API no WordPress 4.7.

Em sua palestra WordPress as Data, 5 Years In, K. Adam White (principal responsável pelo desenvolvimento inicial e lançamento da WP REST API) descreveu que os contribuidores esperavam que a REST API fosse amplamente utilizada assim que fosse lançada com o core. Mas isso não aconteceu: os desenvolvedores continuaram criando sites WordPress da mesma forma que antes, prestando pouca atenção ao headless ou à REST API.

A situação mudou apenas mais tarde, com a introdução do editor Gutenberg no WordPress 5.0, que era baseado na REST API. Poderia o Gutenberg então justificar a adição do GraphQL ao core do WordPress?

​

2. O headless já é atendido via REST API

O editor do WordPress pode ser aprimorado com um servidor GraphQL nativo, permitindo que desenvolvedores de blocos utilizem GraphQL (além da REST API existente) para buscar dados para seus blocos. Além disso, temas e plugins poderiam fazer uso do GraphQL para alimentar suas próprias funcionalidades internas. Esses são motivos fortes para adicionar GraphQL ao core do WordPress.

No entanto, o WordPress já possui a REST API, e tudo o que você pode fazer com GraphQL também pode ser feito com REST. Introduzir GraphQL além do REST é como comprar uma BMW quando você já está dirigindo uma Toyota. Você chegará ao seu destino mais rápido, e a experiência de dirigir será mais agradável. Mas ambos os carros vão levá-lo até onde você quer ir.

Como o GraphQL não fornecerá uma funcionalidade anteriormente indisponível, sua inclusão no core não é totalmente justificada. O GraphQL certamente melhoraria a experiência de interação com a API, mas isso poderia ser perfeitamente considerado território de plugins.

​

3. Temas e plugins do WordPress podem usar webonyx/graphql-php

Plugins públicos não podem exigir que um site instale WPGraphQL ou Gato GraphQL para usar o plugin, pois isso diminuiria seu alcance potencial. Como tal, plugins públicos não podem depender do GraphQL, e isso é uma pena de verdade.

Pensei bastante sobre esse problema e cheguei a uma solução potencial: a GraphQL API Private, um motor GraphQL autossuficiente que os plugins podem incorporar para uso próprio, distribuído como um pacote Composer. (Ainda não comecei a trabalhar neste projeto.)

Mas então, algumas semanas atrás, um plugin WordPress alimentado por GraphQL foi lançado. Fiquei me perguntando como o autor fez isso: estaria usando WPGraphQL ou Gato GraphQL por baixo dos panos? Então verifiquei o código-fonte e, como se vê, ele está usando diretamente o webonyx/graphql-php!

Essa é uma solução interessante, que demonstra que, com um pouco de esforço, os desenvolvedores atualmente têm acesso ao GraphQL para seus temas e plugins.

Este plugin usa GraphQL para buscar suas próprias entidades de dados, e não as do WordPress (posts, usuários, comentários, etc.). Portanto, não precisa recriar o schema GraphQL contendo o modelo de dados do WordPress, como fazem WPGraphQL e Gato GraphQL (e eventualmente a GraphQL API Private). Como tal, depender do webonyx/graphql-php faz sentido.

​

4. GraphQL apresenta riscos adicionais

Os três problemas acima sugerem que o GraphQL melhoraria o WordPress, mesmo que não seja extremamente convincente. Nessa perspectiva, ainda poderíamos adicionar GraphQL ao core do WordPress, e ou nos beneficiar disso ou nada acontecer.

Mas este 4º problema sugere que, se o GraphQL não vai agregar muito valor ao WordPress, então não deveria ser adicionado, por causa de seus riscos adicionais.

O GraphQL é suscetível aos seguintes vetores de ataque (entre outros):

• O endpoint único fornece acesso a todas as informações do site, então poderíamos ter dados privados expostos involuntariamente.
• As queries podem ser muito complexas e podem sobrecarregar os servidores web e de banco de dados.
• A mesma mutation pode ser executada várias vezes em uma única query, e múltiplas queries podem ser executadas juntas em uma única requisição, permitindo que atacantes tentem obter acesso ao back-end fornecendo muitas combinações de usuário/senha.

Esses ataques podem ser realmente danosos. Em sua apresentação Damn GraphQL - Defending and Attacking APIs, o pesquisador de cibersegurança Dolev Farhi conseguiu derrubar um site WordPress em menos de 30 segundos, atacando o endpoint do WPGraphQL com um batch de queries complexas.

O time do WPGraphQL corrigiu o problema imediatamente. Mas como podemos ter certeza de que nenhum outro exploit pode ocorrer? (Quero dizer não apenas WPGraphQL, mas também o Gato GraphQL.)

Esses ataques podem acontecer com GraphQL, e não com REST, porque GraphQL é mais poderoso que REST. Enquanto em REST a query é definida com antecedência e armazenada no servidor, em GraphQL ela é fornecida em runtime pelo cliente (a menos que se usem queries persistidas).

Se os administradores de sites forem descuidados ao configurar quem pode acessar o endpoint, ou quais dados ficam expostos, coisas ruins podem acontecer. E devido à popularidade do WordPress, que é usado por milhões de pessoas que não são especialistas em tecnologia, as coisas ruins muito provavelmente acontecerão.

​

Conclusão

Só para ter certeza: não estou defendendo que não se use GraphQL no WordPress (claro que não estou!), mas que se use GraphQL de forma responsável. GraphQL é poderoso, o que significa que é perigoso. Ao usar GraphQL, precisamos ter certeza de que sabemos o que estamos fazendo.

Distribuir GraphQL no core do WordPress o colocaria nas mãos de muitas pessoas, muitas das quais não estarão cientes de seus riscos e não tomarão as medidas adequadas. É uma receita para um potencial desastre. E como tal, é agora minha opinião que isso deve ser evitado.