export default {
    hello(){
        return { text: "Hello World!", views: 100 };
    }
}

Um resolver é basicamente uma função que é disparada quando uma determinada query é feita, ou seja, se temos uma query com nome “hello” no schema, temos de ter um resolver de mesmo nome para que essa query funcione, que é o que fiz acima. O objeto retornado atende perfeitamente ao schema dessa query, conforme vimos antes.

Agora vamos integrar o GraphQL ao Express, pra ele ser servido no endpoint graphql:

import { graphqlHTTP } from "express-graphql";
import schema from "./graphql/schema.js";
import resolvers from "./graphql/resolvers.js";
 
app.use("/graphql", graphqlHTTP({
    schema,
    rootValue: resolvers,
    graphiql: true
}));

Aqui não tem muito mistério: começamos importando a dependência do express-graphql, do schema e do arquivo de resolvers, para então fornecer na rota /graphql o middleware do mesmo. O último parâmetro não importa agora, vou falar dele depois. Agora suba o seu servidor novamente e vá ao Postman para fazermos o teste, lembrando que ele tem de ser um POST, por isso a necessidade de ferramenta.

No Postman você vai criar um POST para o endereço do seu servidor, mais especificamente no endpoint onde está servindo o GraphQL. O grande segredo aqui é o conteúdo do body da requisição, que deve ser um JSON uma propriedade query, do tipo string, com um objeto contendo o schema da consulta. Neste schema, você informa o nome do resolver a ser utilizado e entre chaves, os campos que deseja ter no retorno, separados por espaço, como abaixo.

E essa é uma vantagem do GraphQL que foi citada antes, quem chama a API é que escolhe os dados que vai receber. Assim, quando essa requisição chega no server GraphQL, a query é analisada, o resolver é acionado e somente os dados necessários são incluídos na resposta, que você consegue ver no body da response na imagem acima. Apesar do hello possuir text e views, a requisição só pediu text e assim foi retornado.

Este meu exemplo é bobo e não faz nada relevante, mas imagine que ele poderia fazer uma consulta no banco de dados, por exemplo.

#4 – Mutações no GraphQL

Antes de avançarmos, lembra que eu deixei um parâmetro sem explicação na inicialização do GraphQL? O parâmetro graphiQL fornece pra gente uma interface gráfica para consultas quando você faz um GET no endpoint do GraphQL, assim você consegue testar diretamete do navegador.

Mas vamos falar agora de mutations, ou seja, operações de escrita usando API GraphQL. O primeiro passo, assim como fizemos antes, é ir no schema.js e criar o schema, sendo que estou mostrando abaixo apenas o que mudou ou é novidade.

input UserInputData {
    name: String!
    email: String!
    password: String!
}
 
type User {
    id: ID!
    name: String!
    email: String!
    logs: [String!]
}
 
type RootMutation {
    createUser(userInput: UserInputData): User!
}
 
schema {
    query: RootQuery,
    mutation: RootMutation
}

No schema definitions na propriedade mutation, o type que lista as funções de escrita (mutações). Tanto as funções de escrita quanto de leitura podem ter parâmetros, sendo que neste caso eu defini um userInput do tipo UserInputData, que definimos logo acima. Como toda boa função, também temos um retorno, que eu definir como obrigatório (!) e como sendo do tipo User, também descrito mais acima.

O tipo User possui alguns campos aleatórios, sendo que dois nos ensinam coisas novas: o id, que é do tipo especial ID (isso diz para o GraphQL que este é o identificador único da entidade) e o logs, que eu defini como um array opcional de strings.

Já o tipo UserInputData, apenas define o objeto com os parâmetros que serão passados para a mutação createUser. Como fizemos antes, o próximo passo é criar o resolver para esta mutação, no arquivo resolvers.js:

createUser({ userInput }, req) {
    const user = {
        id: Math.random().toString(),
        name: userInput.name,
        email: userInput.email,
        logs: []
    };
    return user;
}

Toda função com parâmetros vai ter um primeiro argumento chamado “args”, que aqui neste exemplo eu já estou destruturando, e um segundo chamado req (request), que é útil em algumas situações. Este meu exemplo é bem bobo e não faz nada na verdade, mas imagine que aqui você colocaria o seu código de salvar o usuário no banco de dados, por exemplo, retornando-o ao final do salvamento.

Agora, ao invés de testar no Postman, você pode testar na interface web do GraphQL, com o seguinte payload de mutation abaixo, que explico a seguir:

mutation {
  createUser(userInput: { 
    email: "contato@luiztools.com.br", 
    name: "LuizTools", 
    password: "123" 
  }) {
    id,
    email
  }
}