GraphQL - Speaker Deck

Slide 1

Slide 1 text

GraphQL

Slide 2

Slide 2 text

/usr/bin/whoami

Slide 3

Slide 3 text

/usr/bin/whoami # @cocafunes

Slide 4

Slide 4 text

/usr/bin/whoami # @cocafunes @delaguilaluis

Slide 5

Slide 5 text

Preámbulo

Slide 6

Slide 6 text

Preámbulo ● Crecimiento (desde el 2015)

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Pero… REST! Actualmente RESTful, con formato de intercambio JSON, es la opción predeterminada al considerar implementar una web API.

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Hello World

Slide 14

Slide 14 text

Query

Slide 15

Slide 15 text

GraphQL: Origins

Slide 16

Slide 16 text

GraphQL: Origins ● 2012: Facebook quiere re-construir sus apps móviles nativas

Slide 17

Slide 17 text

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?)

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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?

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Grafo Película How to Lose a Guy in 10 Days Name Director Director Name Donald Petrie

Slide 23

Slide 23 text

Grafo + RootQuery Película How to Lose a Guy in 10 Days Name Director Director Name Donald Petrie Root Query movieById(id: 12345)

Slide 24

Slide 24 text

Principios del diseño

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Pros ● Menos “overhead” de red

Slide 30

Slide 30 text

Pros ● Menos “overhead” de red ● Esquema fuertemente tipado

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

● Más complejo (que una solución REST) Cons

Slide 37

Slide 37 text

Cons ● Más complejo (que una solución REST) ● Caching

Slide 38

Slide 38 text

Cons ● Más complejo (que una solución REST) ● Caching ● Versioning

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Workshop