O Facebook descreve o GraphQL como "uma linguagem de consulta para APIs e um ambiente de tempo de execução para realizar essas consultas com seus dados existentes." Diferentemente de chamadas REST onde um cliente requisita um ponto final REST para alguma coisa, consultas GraphQL permitem que o cliente especifique o que ele está procurando.
Apesar do GraphQL ser fortemente usado no Facebook, sua especificação ainda está nos primeiros dias na comunidade. A InfoQ se reuniu com Steve Faulkner, diretor de engenharia na Bustle, para conversar sobre GraphQL, como é usado na Bustle, e o que os times interessados na GraphQL deveriam considerar.
InfoQ: Como o GraphQL é usada na Bustle?
Steve Faulkner: No momento, o GraphQL é utilizado em tudo que está em produção. Todas as nossas APIs, todo o backend dos CMSs, assim como o frontend de nossos sites, todos conversam com o GraphQL. Temos duas partes de código separadas na Bustle: temos a parte de backend do CMS, que é interno e personalizado e temos nosso frontend Preact app renderizado no lado do servidor que conversa com a GraphQL como parte disso.
InfoQ: O que a Bustle mudou?
Faulkner: Estávamos usando todo o tipo de coisas REST. O estilo Rails de convenções REST era como tudo funcionava por aqui. No começo, eu não era realmente um fã de GraphQL. Fui fortemente contra as pessoas que estavam tentando trazê-lo para a Bustle. Pensava: "REST é bom o bastante, ele faz todas essas coisas; esse tal GraphQL é muito complicado, eu não sei como vai se encaixar aqui; Não quero fazer nossas tecnologias mais complicadas do que devem ser".
Mas existem duas coisas que realmente me animaram para a mudança. A primeira foram os tipos. Quando eu comecei a brincar e a usar os tipos, tivemos uma ajuda com muitos problemas de comunicação entre desenvolvedores. Não era uma coisa tão técnica, estava melhorando nossa habilidade de desenvolver mais rápido. A segunda foi o quão rápido nosso pessoal de frontend se apegou. Estávamos experimentando em produção e de repente nós estávamos usando para uma quantidade enorme de coisas, na maioria das vezes porque nossos desenvolvedores não precisavam pedir para ninguém. Eles podiam dizer: "Oh, preciso de uma nova consulta formada de uma maneira diferente. Posso fazer isso. "
InfoQ: Como a decisão de mudança aconteceu?
Faulkner: Na Bustle há muita liberdade para o nosso time de engenharia. Confiamos em todos os nossos desenvolvedores para construir novas coisas que eles acreditam que devem existir. Um dos nossos desenvolvedores disse, "Acho que GraphQL é o futuro", e acho que ele estava certo sobre isso. Começamos a brincar com isso. Temos uma política de que se vermos alguma coisa legal e quisermos brincar com isso, colocamos em produção para ver como se comporta. Temos partes do site que são pequenas e fáceis para brincarmos.
InfoQ: Quais os tipos de problemas que foram solucionados?
Faulkner: O maior problema é a comunicação entre as pessoas. Como você se comunica sobre mudanças de APIs e documentação? Tudo isso vem no pacote com o GraphQL. É uma linguagem para desenvolver APIs muito mais estrita que REST. Força você em utilizar os melhores padrões, mas também permite que a documentação seja gerada automaticamente. O explorador da API (GraphiQL) funciona automaticamente. Ele remove todos os problemas não difíceis, mas são problemas que pessoas precisam gastar tempo arrumando. E quando você os elimina, você pode desenvolver mais rápido.
InfoQ: Quais questionamentos os times deveriam se fazer caso estejam considerando mudar para GraphQL?
Faulkner: Penso que existem algumas deficiências [no GraphQL], especialmente quanto: à segurança e operação em ambiente de produção e a complexidade de consultas, autorização e autenticação. Resolvemos muito disso por nós mesmos, mas eles ainda não estão resolvidos em uma amplitude de comunidade. Imagino que as pessoas devem se preocupar com isso. Se você é um banco e quer fazer um "endpoint" com GraphQL, você deveria pensar seriamente sobre "quais passos extras precisaremos dar para realmente colocar isso em produção?"
Faulkner palestrou na QCon Londres 2017 sobre como a Bustle usa "serverless" para deixar seu backend mais poderoso.