Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TDC POA - GraphQL

TDC POA - GraphQL

Ana Luiza Portello

January 22, 2020
Tweet

More Decks by Ana Luiza Portello

Other Decks in Programming

Transcript

  1. Olar! Meu nome é Ana Bastos Sou engenheira de software

    e cientista da computação. 2 anabastos @naluhh @anapbastos
  2. 3

  3. HTTP GET Songs Followers Ana Luiza Lorem Ipsum users/123 RESPONSE

    a { name: .., accountName: .., nickname: Ana Luiza, email: {..}, bio: Lorem Ipsum avatar: {..}, birthday: .., city: .., location: {..} ... }
  4. HTTP GET Songs Followers Ana Luiza Lorem Ipsum users/123/posts RESPONSE

    posts { { id: .. music: {..}, replies: {..}, likes: {..}, shares: {..}, … }, ... } Jovelli How I Feel
  5. HTTP GET Songs Followers Ana Luiza Lorem Ipsum users/123/followers RESPONSE

    followers { { name: .., accountName: .., Nickname: Vilmar, email: {..}, avantar: .. … }, ... Jovelli How I Feel
  6. - Underfetching gerando a necessidade de fazer muitas requisições ou

    de criar endpoints muito específicos - Overfetching e com isso problemas em performance
  7. “Ficamos frustrados com as diferenças entre os dados que queríamos

    e as requisições que eram necessárias para obtê-los” Lee Byron
  8. Desenvolvedores do Facebook - Mano vamo ter que usar SOAP.

    - Puts mas SOAP usa XML. Pra JS é tudo JSON. Seria loco se a gente usasse SOAP com JSON. - Hold my beer
  9. SOAP 2.0 / GraphQL Auto-documentação Tipos / Schemas Usa JSON

    ao invés de XML e chama de uma linguagem nova
  10. type Post { id: ID artist: String album: String music:

    String genre: String likes: Int }
  11. type User { id: ID name: String avatarUrl: String description:

    String age: Integer status: Status musicalTaste: [String] posts: [Post] followers: [Follower] } enum Status { Active Blocked Inactive }
  12. Schemas descrevem o contrato entre o front e o back

    e o relacionamento entre os dados
  13. HTTP POST graphql/ RESPONSE data { userName: .., avatar: ..,

    bio, followers [ {avatar: ..}, .. ] posts [ {artist: …, name:} BODY query profile{ user { name description } followers{ avatar } posts { artist name } }
  14. HTTP POST graphql/ RESPONSE data { userName: .., avatar: ..,

    bio, followers [ {avatar: ..}, .. ] posts [ {artist: …, name:} BODY query profile { user { name description } followers{ avatar } posts(first: 5, orderBy: “date”) { artist name } }
  15. HTTP POST graphql/ RESPONSE data { userName: .., avatar: ..,

    bio, followers [ {avatar: ..}, .. ] posts [ {artist: …, name:} BODY query profile { user { musicalTaste } followers(first: 4){ avatar } popularPosts(first: 5, orderBy: “popularity”) { artist name } }
  16. HTTP POST graphql/ RESPONSE data { status: “ok” } BODY

    mutation addPost { artist: “...” name: “...” album: “...” } }
  17. HTTP POST graphql/ RESPONSE ERRO BODY mutation addPost { artist:

    “...” name: 1 album: { name: “aa” } } }
  18. REQUEST subscription { subscribeToComment (filter : { mutation_in : [CREATED]

    }){ comment { content author { username } } } } RESPONSE { “data”: { comment { content: “Nossa”, author { username: “Ana” } } } } RESPONSE { “data”: { comment { content: “Eita”, author { username: “Joao” } } } }
  19. CLIENT SERVER GRAPHQL DATA RESOLVE BODY JSON { query: {..}

    variables:{..} } { data: {..} errors:{..} } G R A P H Q L
  20. Já que GraphQL é agnostico de dados cada query ou

    mutation tem uma função resolver e nela é nossa responsabilidade buscar e estruturar os dados de acordo com o Schemas da forma mais perfomática pois o muitas vezes o client pode solicitar diversos dados com alta complexidade por de baixo dos panos
  21. BODY query profile { user { folowers: [ user: {

    folowers: { user:... } } ] } Maximum depth: 3
  22. Mutations definem uma série de ações que mudam seus dados.

    Subscriptions definem uma série de eventos que você pode se inscrever(subscribe) pra quando os dados mudam.
  23. RESPONSE { getPosts { ‘content’: { ... } } }

    REQUEST subscription getPosts($post: Post) { getPosts(content: $post){ content } }
  24. type Post { id: ID artist: String album: String music:

    String genre: String likes: Int }
  25. DIFERENTES CLIENTES: Há a necessidade de criar várias versões de

    dados diferentes para múltiplos clientes. LINKAR DADOS: Quando os dados mudam com muita frequência e precisam estar linkados sempre. NECESSIDADE DE ENDPOINTS MUITO ESPECIFICOS
  26. HYPE: Minha empresa gosta do stack do facebook e todo

    mundo acha mo hype. O FRONTEND SUGERIU REST É ANTIGO kk TOO NORMALIZED: Tenho muitas relações.
  27. GraphQL Rest API HTTP METHODS POST GET POST PUT ETC

    Status Code Precisa lidar com todos os errors Default Cache do proprio navegador Precisa usar DataLoader. Default Peso da request Mais leve pois é só o necessário Overfetching / Underfetching Complexidade Escondida embaixo do tapete Explicita Documentação Default Precisa implementar
  28. TIPS Deixar models extremamente dinâmicas(limits, orders, filters, pegar apenas os

    campos requisitados na query GraphQL). Usar context do graphQL para guardar estado Crie seu proprio status code