GraphQL

 GraphQL

Intro to GraphQL before workshop done with the Guatemala's Facebook Developer Circle (spanish).

E4320280d01039bbe4a021b12e8eac8b?s=128

Luis Del Aguila

March 21, 2018
Tweet

Transcript

  1. GraphQL

  2. /usr/bin/whoami

  3. /usr/bin/whoami # @cocafunes

  4. /usr/bin/whoami # @cocafunes @delaguilaluis

  5. Preámbulo

  6. Preámbulo • Crecimiento (desde el 2015)

  7. Preámbulo • Crecimiento (desde el 2015) • Empezó a trabajarse

    en 2012 en Facebook
  8. Preámbulo • Crecimiento (desde el 2015) • Empezó a trabajarse

    en 2012 en Facebook • Existe un borrador de la especificación
  9. Preámbulo • Crecimiento (desde el 2015) • Empezó a trabajarse

    en 2012 en Facebook • Existe un borrador de la especificación • Se ha implementado en clientes en más de 10 lenguajes distintos
  10. Pero… REST! Actualmente RESTful, con formato de intercambio JSON, es

    la opción predeterminada al considerar implementar una web API.
  11. El nuevo chavo de la cuadra GraphQL es una manera

    completamente nueva de implementar y consumir Web APIs. Y, si se hace bien, se puede construir integraciones maravillosamente acopladas que no son posibles con REST.
  12. El nuevo chavo de la cuadra GraphQL es una manera

    completamente nueva de implementar y consumir Web APIs. Y, si se hace bien, se puede construir integraciones maravillosamente acopladas que no son posibles con REST. http://graphql.org/
  13. Hello World

  14. Query

  15. GraphQL: Origins

  16. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas
  17. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas • Existen diferencias entre cómo se guarda el contenido y cómo se desea mostrar (news feed?)
  18. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas • Existen diferencias entre cómo se guarda el contenido y cómo se desea mostrar (news feed?) • ¿Grafos? Así no se almacena ¯\_(ツ)_/¯
  19. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas • Existen diferencias entre cómo se guarda el contenido y cómo se desea mostrar (news feed?) • ¿Grafos? Así no se almacena ¯\_(ツ)_/¯ • ¿Grafos con REST?
  20. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas • Existen diferencias entre cómo se guarda el contenido y cómo se desea mostrar (news feed?) • ¿Grafos? Así no se almacena ¯\_(ツ)_/¯ • ¿Grafos con REST? • ¿En móviles?
  21. GraphQL: Origins • 2012: Facebook quiere re-construir sus apps móviles

    nativas • Existen diferencias entre cómo se guarda el contenido y cómo se desea mostrar (news feed?) • ¿Grafos? Así no se almacena ¯\_(ツ)_/¯ • ¿Grafos con REST? • ¿En móviles? Solución: obtener la data desde la perspectiva de los diseñadores de producto y desarrolladores
  22. Grafo Película How to Lose a Guy in 10 Days

    Name Director Director Name Donald Petrie
  23. Grafo + RootQuery Película How to Lose a Guy in

    10 Days Name Director Director Name Donald Petrie Root Query movieById(id: 12345)
  24. Principios del diseño

  25. Principios del diseño • Es de naturaleza jerárquico, eso quiere

    decir que podemos seguir las relaciones entre objetos de manera natural. Y esto se acerca a como comúnmente pensamos en nuestras interfaces.
  26. Principios del diseño • Es de naturaleza jerárquico, eso quiere

    decir que podemos seguir las relaciones entre objetos de manera natural. Y esto se acerca a como comúnmente pensamos en nuestras interfaces. • Es fuertemente tipado, cada nivel en un query corresponde a un tipo, y cada tipo define un set de campos (propiedades). Esto permite dar errores más descriptivos antes de ejecutar un query.
  27. Principios del diseño • Es de naturaleza jerárquico, eso quiere

    decir que podemos seguir las relaciones entre objetos de manera natural. Y esto se acerca a como comúnmente pensamos en nuestras interfaces. • Es fuertemente tipado, cada nivel en un query corresponde a un tipo, y cada tipo define un set de campos (propiedades). Esto permite dar errores más descriptivos antes de ejecutar un query. • Es libre de versionamiento dado que los clientes hacen en el query exactamente la data que necesitan, se pueden añadir campos sin preocupación de romper algo o hacer las respuestas más pesadas.
  28. Conceptos • Los tipos, y los campos (propiedades) en dichos

    tipos • Los tipos escalares que incluye son: ◦ Int ◦ Float ◦ String ◦ Boolean ◦ ID • Se pueden definir escalares personalizados
  29. Pros • Menos “overhead” de red

  30. Pros • Menos “overhead” de red • Esquema fuertemente tipado

  31. Pros • Menos “overhead” de red • Esquema fuertemente tipado

    • Encaja muy bien con data “tipo grafo”
  32. Pros • Menos “overhead” de red • Esquema fuertemente tipado

    • Encaja muy bien con data “tipo grafo” • No obliga a tener un motor de almacenamiento en específico
  33. Pros • Menos “overhead” de red • Esquema fuertemente tipado

    • Encaja muy bien con data “tipo grafo” • No obliga a tener un motor de almacenamiento en específico • Se obtiene lo que se pide
  34. Pros • Menos “overhead” de red • Esquema fuertemente tipado

    • Encaja muy bien con data “tipo grafo” • No obliga a tener un motor de almacenamiento en específico • Se obtiene lo que se pide • Introspección
  35. Pros • Menos “overhead” de red • Esquema fuertemente tipado

    • Encaja muy bien con data “tipo grafo” • No obliga a tener un motor de almacenamiento en específico • Se obtiene lo que se pide • Introspección • No hay versionamiento
  36. • Más complejo (que una solución REST) Cons

  37. Cons • Más complejo (que una solución REST) • Caching

  38. Cons • Más complejo (que una solución REST) • Caching

    • Versioning
  39. Cons • Más complejo (que una solución REST) • Caching

    • Versioning • Todavía muy “temprano”
  40. Cons • Más complejo (que una solución REST) • Caching

    • Versioning • Todavía muy “temprano” • Expuesto para queries arbitrarios
  41. Cons • Más complejo (que una solución REST) • Caching

    • Versioning • Todavía muy “temprano” • Expuesto para queries arbitrarios • Modelar side-effects (o “controllers”)
  42. Cons • Más complejo (que una solución REST) • Caching

    • Versioning • Todavía muy “temprano” • Expuesto para queries arbitrarios • Modelar side-effects (o “controllers”) • Monitoreo con herramientas existentes
  43. Workshop