Thread by @jgcmarins

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Eu parei de listar as vantagens do GraphQL.
Prefiro ajudar as pessoas a enxergarem da seguinte forma:
SOAP evoluiu e virou REST. REST evoluiu e virou GraphQL.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Porquê deixamos de usar SOAP?
- XML ruim
- protocolo antigo
- JSON muito melhor

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê fomos para o REST?
- JSON S2
- API versionadas (api/v1, api/v2)
- endpoints auto explicativos (api/v1/users, api/v1/user/:id)
- mais fácil de ser consumido pelos clients mobile

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê deixamos de usar REST?
- overfetching: eu preciso do nome da pessoa. A API devolve o sobrenome, e-mail, nome da mãe, pai, papagaio, cachorro
- underfetching: eu preciso do nome da pessoa e do nome dos amigos. A API me dá o nome em uma request, e a lista de amigos em outra

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê deixamos de usar REST? (part 2)
- versioning: api/v1, api/v2, api/v3. Se o user nunca atualizar o app, ele consumir da api/v1 o resto da vida.
- contrato: se seu JSON retorna tudo string, como o front sabe os types? Como eu sei que "2" é string ou number?

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê deixamos de usar REST? (part 3)
- ainda sobre contratos: como o client side sabe que "Joao" eventualmente pode ser null? Rest não é fortemente tipado. O client pode receber qualquer type e pode enviar qualquer type.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê deixamos de usar REST? (part 4)
- viewerCanSee: o client pode ver tudo. Se eu pedir api/v1/user/123, a API vai me devolver todo os fields do user 123. O único jeito de resolver isso é fazer endpoints diferentes que respondam com grupos de dados semelhantes.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê fomos para GraphQL?
- ask what you need: se eu pedir o nome do usuário e apenas o nome, o GraphQL devolve somente o nome, nada mais. Não existe overfetching e não existe underfetching.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê fomos para GraphQL? (part 2)
- versioning: o endpoint é um só /graphql. Os clients sempre terão acesso ao backend mais recente.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme Por quê fomos para GraphQL? (part 3)
- fortemente tipado: @GraphQL + @RelayModern. Se o input da sua mutation de mudar nome do usuário espera nome do tipo string, qualquer dev que usar essa mutation será obrigado a passar esse field. Relay compila todas as queries e te obriga.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern Por quê fomos para o GraphQL? (part 4)
- ainda sobre type safe: se você pede por um field "número do telefone" do tipo string ou null o @RelayModern vai te avisar que eventualmente aquele dado poderá ser null.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern Por quê fomos para o GraphQL? (part 5)
- viewerCanSee: um user comum e um user admin vão pedir o mesmo UserType, mas no contexto do GraphQL da pra saber quem fez a request e decidir quais fields estarão disponíveis. O viewerCanSee decide se um field resolve ou não o dado.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern Pra concluir, recomendo este artigo de 2017 do @samerbuna:
“REST APIs are REST-in-Peace APIs. Long Live GraphQL.” by Samer Buna link.medium.com/x1XT3xAySX

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern @samerbuna Por quê deixamos de usar REST? (part 5)
- autodocumentação: REST não é autodocumentável. Você implementa e depois escreve a documentação.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern @samerbuna Por quê fomos para GraphQL? (part 6)
- autodocumentação: GraphQL é autodocumentado. Ao implementar um resolver, um dos fields esperados é a "description". Da pra visualizar todas as queries, mutation e subscriptions no @GraphiQL.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern @samerbuna @GraphiQL Este Tweet do @sseraphini

https://twitter.com/sseraphini/status/1144584540213731328

fez eu me lembrar de mais alguns pontos.
HTTP methods pareciam uma boa ideia. Você faz GET, POST, PUT, DELETE e ... cada API usa isso de um jeito.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern @samerbuna @GraphiQL No GraphQL todas as chamadas são POST.
Os recursos disponíveis são: query, mutation e subscription.
Uma #query é uma consulta de informações.
Uma #mutation é uma mudança de informação. Pode ser criar, atualizar, remover. O backend é quem resolve isso pro client.

@RobertoAchar @jeanjmichel @sseraphini @jabur_guilherme @GraphQL @RelayModern @samerbuna @GraphiQL E uma #subscription é uma mutation de outro client. Quando um client x muda um dado, todos os clients que deram subscription nesse dado vão receber essa atualização.