GraphQL, é uma boa já colocar em produção? Algum case com GraphQL + Serverless?

[wilsongomes-swe]

Galera,

sobre GraphQL, qual a opinião de vocês, eu estudei bem pouco, mas vejo crescendo tanto que agora peguei esses dias de folga para estudar e entender de vez, porém... acham legal já usar em produção?

Acham que futuramente esta pode substituir o Rest? Acham que as duas podem co-existir? Alguém já usando?

Abraços!

[ninetails]

Usando, tem os vanguardistas, os hyperos, alguns demos, listagem oficial...

Não há problemas em usar em produção.

Porém o que eu sempre digo é: a ferramenta pro case certo. Querendo ou não, é uma curva a mais a adicionar pros devs.

Porém, para React é uma ferramenta que casa muito bem e diminuindo uso de Redux (pra quem curte) pois além de unificar requisições, vc pode fazer uma arquitetura onde a hidratação beneficia componentização.

[nandomoreirame]

Aqui na empresa estamos implementando em nossa API Nodejs e no APP Vuejs.

Veja esse repo aqui de cases de Empresas que usam GraphQL no Brasil.

[ninetails]

Aliás, tem também um Slack do [GraphQL BR]](https://graphql-slack.now.sh/) da mesma galera do Slack do React Brasil e dos meetups do ReactSP.

[kavalcante]

Cara, utilizamos em produção há mais de 2 anos. Pode parecer que somos muito hyperos, mas acredite, não somos.

No nosso caso, fez todo sentido, especialmente a questão de ser fortemente tipado (o que deu uma consistência legal na aplicação), a documentação que ele gera e o fato do front-end poder buscar somente o que precisa.

A gente apanhou muito nesses 2 anos (no começo muitos problemas que tinhamos, era necessário chamar no slack, pq ninguém tinha vivido o problema ainda), mas hoje já estamos maduros o suficiente e pelo menos pra mim, foi uma das melhores decisões que tomamos. Nossa stack é composta de: Node.js (com Apollo, inclusive assinamos o Apollo Engine), Nuxt.js com vue-apollo e Mongodb como banco de dados.

A gente comete um erro até hoje que é usar o GraphQL como muleta, fazendo com que o GraphQL faça o join de collections no mongodb. Mas não é um problema do GraphQL, mas sim da nossa arquitetura e que estamos corrigindo aos poucos.

[valkervieira]

Cara, utilizamos em produção há mais de 2 anos. Pode parecer que somos muito hyperos, mas acredite, não somos.

No nosso caso, fez todo sentido, especialmente a questão de ser fortemente tipado (o que deu uma consistência legal na aplicação), a documentação que ele gera e o fato do front-end poder buscar somente o que precisa.

A gente apanhou muito nesses 2 anos (no começo muitos problemas que tinhamos, era necessário chamar no slack, pq ninguém tinha vivido o problema ainda), mas hoje já estamos maduros o suficiente e pelo menos pra mim, foi uma das melhores decisões que tomamos. Nossa stack é composta de: Node.js (com Apollo, inclusive assinamos o Apollo Engine), Nuxt.js com vue-apollo e Mongodb como banco de dados.

A gente comete um erro até hoje que é usar o GraphQL como muleta, fazendo com que o GraphQL faça o join de collections no mongodb. Mas não é um problema do GraphQL, mas sim da nossa arquitetura e que estamos corrigindo aos poucos.

Qual produto principal?

Faz sentido GraphQL com eCommerce? Esse ano aqui na firma (fazemos só eCommerce) provavelmente vamos modernizar nossa stack (vanilla + jekyll/liquid) e eu tenho a impressão que praticamente todas as nossas consultas na api tem over fetching ou under fetching, a gente vive pedindo pro back criar uma chamada nova e etc que sempre demora pra ser implementada por que os caras tem outras demandas e tal...

[wilsongomes-swe]

@borghettinho , uma dúvida para você também kkk Pelo que entendi vocês usam Vanilla + Jekyll, certo? Porque optaram por esta stack no lugar de digamos React + Next? Chegaram a usar também, consegue dar um comparativo de prós e contras de uma frente a outra?

Abraços!

[valkervieira]

@wilsonneto-dev a empresa está com a stack por mais ou menos uns 9 anos, temos 200 lojas online com ela. Acontece que nosso produto de back evoluiu muito, hoje roda em React/Node/Express/TS/ com testes, CI e tudo bonitinho pra nos servir os dados. Enquanto a gente aqui no front ainda usa jQuery, não tem acesso aos endpoints da api, faz deploy manual e etc.

Eu me interessei pela tua questão por que GraphQL é a principal forma de acesso aos dados no Gatsby, e quando nos reunirmos pra discutir a mudança de stack eu provavelmente vou votar nele por que eu realmente gostaria de trabalhar com Gatsby e continuar trabalhando aqui. kkk O problema é que eu não manjo de GraphQL o suficiente pra argumentar em favor do mesmo.

Jekyll é linguagem de template né, então a gente não tem flexibilidade nenhuma, não temos acesso aos endpoints da API, por isso quando a aplicação exige alguma funcionalidade mais disruptiva, dependemos ou da criação de uma tag pelo back, ou de gambiarras (que é o mais comum) que costumam resultar em mais chamadas na api ou chamadas ineficientes.

Eu quero sugerir Gatsby pensando na ideia de um single endpoint e de delegação de responsabilidade pra nós do front usarmos os dados como bem entendermos, eu só não sei se numa situação como a nossa servir os dados pra serem consumidos pelo Gatsby exigiria muita energia do pessoal de back, imagino que sim, ou sequer se essa necessidade existe, se talvez só ter acesso aos endpoints já resolveria.

Talvez alguém que já fez essa troca sabe dizer se vale a pena.

[kavalcante]

@borghettinho Nós temos um sistema B2B, que tem o mesmo público alvo que um ERP, por exemplo. Então, no nosso caso, performance não é um problema como pra você deve ser. Nossas decisões foram para facilitar o desenvolvimento mesmo e vou explicar porque GraphQL nos ajudou nesse sentido.

Como te falei, essa questão de performance para a gente, não era um problema tão grande. Já que nossos usuários são corporativos, o sistema tem que ser rápido o suficiente, mas não incrivelmente rápido como um ecommerce, normalmente. Então o under e over fetch que o GraphQL resolve, foi puramente por uma questão de melhorar o ciclo de desenvolvimento mesmo. Na nossa stack, o front-end atua muito mais. E isso nos deu uma liberdade muito boa para expandirmos para o mobile (que iremos lançar ano que vem, provavelmente).

O nosso back-end hoje realmente atua como um núcleo meio independente dos clients que consomem ele. Então a parte de documentação e o controle que você tem sobre o que você quer consumir é muito bom.

Eu particularmente, acho que só a documentação em si, já vale a pena demais. Coisa que com REST, você precisa dar uma volta grande pra fazer. Fora a parte de ter que estruturar as rotas e tais. No GraphQL isso funciona muito como uma query mesmo, que tá lá pronta pra você.

A imagem abaixo, exemplifica uma chamada no Vue, de uma query do GraphQL:

Basicamente, eu posso fazer chamadas em qualquer componente que eu quiser. Eu não preciso ficar lembrando qual rota é. Apenas preciso criar o arquivo com a query em questão (ou as queries, pois posso fazer mais de uma e agrupá-las na mesma chamada) e depois decidir o que vou fazer com o resultado dela. Nesse caso, ele joga o retorno automaticamente na minha variável contract.

Então assim, eu posso trocar toda a stack nossa de back e front, pois Vue e React são tudo iguais. Mas uma coisa que eu acho que nunca voltaria atrás é no GraphQL. Pois tirando cenários onde a gente precisa integrar com outros sistemas externos que não usam GraphQL, ele é muito bom pra se comunicar seja client > server, server > server e assim por diante. É uma linguagem bem sólida e muito inteligente.

Espero que tenha sido claro, se tiver alguma dúvida, ficarei feliz em ajudar.

[valkervieira]

@kavalcante caraca, claríssimo, essas chamadas parecem muuuito legíveis. Valeuzão pelo exemplo, casa bastante com nosso cenário aqui.