Pues ya estamos aquí, en el último vídeo de esta colección de introducción para GraphQL, React, React Apollo y también para hacer la parte del backend.
Eso es.
Wow, hemos llegado lejos, ¿eh?
Sí, sí, sí. Parece poco, pero hay mucho contenido aquí, muy interesante.
Mucho para estudiar, mucho para hacer. Muchísimas gracias Horacio por todo tu tiempo.
Gracias, gracias.
Es brutal.
Vamos a terminar por todo lo grande.
Venga.
Fetch.
Porque, claro, hemos visto que estábamos devolviendo todo esto de bugs. Vamos a quitar todo el tema de bugs para irle entrando, ¿vale?
Venga, yo creo que sí está bien.
Si quieren quitar comentarios también.
Sí, vamos a quitar bugs.
Esto lo pueden ver en el repo.
Sí, no se preocupen. Aquí esto de bugs fuera y el resolver de bugs también.
¿Dónde nos habíamos quedado? Pues teníamos los carácteres que lo estábamos sacando directamente de este mock que tenemos aquí.
Estábamos devolviendo directamente y aquí en el playground pues ya podíamos haberlo devuelto.
Pero, ¿qué queríamos hacer Horacio ahora?
Vamos a buscar, a recibir los carácteres de la API REST. Vamos a conectar la API REST aquí.
Vamos a hacer más que nada de verdad.
Claro, porque esto de local no tiene mucha gracia. Vamos a hacerlo de verdad, ¿no?
Exacto. Entonces, aquí mirando la API de Rick and Morty, la API REST, podemos ver que para recuperar los carácteres lo que podemos hacer es acceder a esta URL.
De hecho, lo voy a pegar aquí y me saldrá todo el JSON. Aquí tengo todo el JSON. Perfecto.
Así que, si me voy equivocando, tú me paras los pies, ¿eh?
Yo voy a crear una función que le voy a llamar fetch characters.
Eso es.
Y no recibe ningún parámetro. Y esto lo que va a hacer es devolver...
Va a devolver el...
Fetch.
Eso es.
De esta URL que es justamente donde tenemos todos los carácteres.
Hacemos un fetch habitual en JavaScript.
En este caso, estamos utilizando fetch porque estamos importando nodefetch.
Pero podéis utilizar un fetch o podríais hacer...
Axios o lo que quieras.
Lo que queráis.
Al final, la API es muy parecida.
Exacto.
Esto nos devuelve una promesa, que es la respuesta.
La respuesta la tenemos que pasear con el JSON para que devuelva bien los datos.
Y ya tendríamos... No sé si ya tendríamos que hacer algo...
Ah, sí. Podemos sacar... No, hay que hacer nada más.
Podríamos sacar los results o eso lo hacemos después.
Sí, podemos hacer los results. Eso es.
Sí, sí. Así es más limpio.
Vale, porque aquí, si miramos aquí, tenemos info.
Que no sé si vamos a querer utilizar la info para nada.
De momento no.
No.
Pero ven, por ejemplo, aquí esto...
Tienes la información de la página.
Claro.
Esto ya está paginado para ti.
O sea, que es importante...
Es interesante si lo quieres resolver.
Luego en esa query tienes que acordarte de que eso es lo que estás recibiendo.
Exacto.
Para simplificarlo, vamos a quedarnos solo con la propiedad results.
Eso es.
Y además, otra cosa importante es que en la query que estamos definiendo...
En el type definition, estamos diciendo que vamos a devolver un array de carácter.
No estamos diciendo que vamos a devolver info y carácters.
¿Ok?
Es súper importante.
Esto es súper importante.
Esto es también saberlo.
Si lo que aquí quieres hacer, el resultado completo, tienes que hacerte tu tipo que tenga el objeto info...
Claro.
Y también el array de carácter.
Claro.
Habría que cambiar totalmente el contrato.
Eso es.
Así que por ahora, esto.
La respuesta que tenemos aquí, que esto ahora sí que es el JSON.
Voy a poner JSON para que la gente lo vea más claro.
Eso es.
Y JSON.results.
Y esto es lo que vamos a devolver con el fetch characters.
Ahora, yo no sé si haciendo ya directamente esto...
Pruebalo, a ver, pruebalo.
Pruebalo, a ver.
Que se puede romper todo.
Vale.
Guardo los cambios.
Vamos al playground.
Ay, qué miedo.
Le doy al play.
Hola.
Hola, la primera.
Muy bien.
Vale, pues ya está fantástico.
Ahora sí, esto está haciendo por detrás una petición a la API REST de Rick and Morty
y nos lo ha transformado todo a lo que queremos con GraphQL.
Y puedes ver en la network que solamente es una query, es una petición.
Vamos aquí.
Eso ya, toda la petición a REST se hace en el server, no se hace aquí.
Desde aquí.
Exacto.
Llegamos aquí.
Hay muy poquito espacio, pero bueno, sí, está haciendo una petición a localhost.
Aquí van saliendo más, pero no tienen nada que ver.
Esto seguro es un...
De playground.
Claro, esto es de playground.
Si ves, ahí hay una bolita que está como parpadeando en la URL.
Sí, ya está.
Esto porque está escuchando al server porque estamos en localhost.
Ya está.
Aquí en localhost tenemos este data con carácter, todo en una sola query, o sea, una sola petición
y ya está.
Que es justo lo que queríamos.
Pues esto está muy bien, Horacio, pero a mí me queda una duda, ¿no?
Porque, vale, tenemos los carácters, ahora ya tengo aquí todos los personajes con el
nombre y su ID, pero imagínate que quiero recuperar un personaje.
¿Esto lo hemos visto?
Eso no se puede.
No, es broma, es broma.
Es broma.
Pásame vos.
Es broma, es broma.
Sí se puede.
Vamos a hacerlo.
Eso es.
¿Cómo?
Ok.
Cosas importantes.
Esta función se va a llamar cada vez que en el cliente de GraphQL se pida esa query.
Esta función está llamada con varios parámetros, ¿no?
Entonces, los más habituales o los principales son los dos primeros, que el primero es el
parent o el origen y el segundo son todos los argumentos que le pasas a esa query.
Entonces, si aquí tú le pones la firma en la línea 32, parent o ponle cualquier nombre
que quieras, esto es, podemos decir que es la query padre.
En este caso, esto va a ser referencia al objeto query inicial.
Pero, claro, ¿esto por qué está así?
Porque en el caso del objeto character, hemos visto que tenemos name, id, status y luego
también tenemos episodes.
Entonces, episodes en la parte de rest es un array de URLs.
Pero si nosotros queremos dentro de episodes poder recibir información específica de cada
uno, tú tienes que hacer ese resolver también.
Entonces, en el caso de episodes, tú puedes ya referir directamente a el parent, que es
el character o characters o el que sea.
Entonces, eso te ayuda un poco a hacer la referencia de su padre y así no tienes líos
por si se pasa un id, que es lo que vamos a hacer ahora, o pasa cualquier cosa.
Tienes acceso a esa información, ¿ok?
Vale, importante.
Entonces, en este caso, parent, no lo necesitamos para definirlo, porque sí que necesitamos
el segundo.
Ah, claro.
Claro, o sea, en character lo dejamos tal cual.
Eso es, perdón, sí.
Pero aquí, exacto, aquí sí que vamos a hacer una nueva para character en singular,
para uno.
Eso es.
Y como comentaba Horacio, es parent, que no lo vamos a usar, pero es todo esto que has
comentado.
Y luego...
Podemos llamarle argumentos, arcs, o como quieras.
Venga, y en arcs vamos a recibir la información que le estamos pasando.
¿Qué vamos a recibir?
Exacto.
Aquí, si quieres, haz una función fácil que sea un console.log.
Perfecto.
De arcs.
Me parece muy bien.
Entonces, con esto, eso es.
Uy, ¿no le ha gustado algo?
Claro.
¿Qué pasa aquí?
Ya me está avisando, me está diciendo, vale, está definido en los resolvers, pero
no en el esquema.
Ahí estamos.
No te portes mal y ve al esquema.
Muy bien.
Claro, entonces aquí le tengo que decir character, que nos va a devolver un character,
del tipo character.
Pero, claro, aquí character que tienes que pedirlo con algo, ¿no?
Ah, claro.
Entonces tienes que pasarle...
El parámetro.
Exacto.
Tienes que pasarle el parámetro a id.
Y el parámetro, esto se hacía así.
Eso es.
Muy bien.
Queríamos...
Id.
Eso es.
¿Qué tipo?
Id.
Eso es.
Este tipo es un scalar type que ya viene definido en GraphQL.
Ya lo hemos mencionado, pero lo vuelvo a mencionar.
Tengo una pregunta.
Porque en el vídeo anterior me has dicho, pero es cuando es requerido, hay que poner
una exclamación.
¿Aquí también?
Aquí creo que también puedes ponerlo.
Sí, no estoy de todo seguro.
Pregunta trampa.
Sí, pero creo que sí.
¿Perdad?
Vale, vale.
Bueno, lo voy a...
Tiene todo el sentido que sea requerido, porque obviamente si no...
Lo voy a dejar y si se queja, pues guardo los cambios y vamos a ver.
Ahora me ha funcionado.
No se ha quejado.
Voy a ir al playground y vamos a intentar hacer aquí una query.
Creo que con...
Bueno, ya se me está quejando.
Vamos a ver que le está...
Ahí, ahí, ahí.
Bueno, voy a...
Recargar.
Sí, porque no sé por qué se me estaba saliendo...
Mira, character y aquí hay que...
Ah, porque tengo que...
Claro, ya me imagino.
A ver, a ver.
Primero, voy a intentar ponerle ahí.
Pero ahora se queja porque, mira, me dice que el parámetro ID está faltando y está requerido.
O sea, que sí queda necesario lo que he requerido.
Aquí entonces era así.
Vamos a poner los hardcoded, si quieres.
Vale, o sea, podemos poner aquí dos directamente.
Pero tienes que poner el nombre ID, dos puntos.
ID, dos puntos.
Eso es.
Dos.
Perfecto.
Y esto recuperaría solo el nombre.
Eso es.
Entonces ahora, si le das el play, no vamos a recibir nada.
¿Por qué?
Porque no estamos devolviendo nada.
Pero si te vas a la consola...
Vale.
Al menos...
No, a la consola de nombre.
Ah, claro, exacto.
Muy bien.
Aquí estás viendo que arcs, eso es, es todo lo que le estás pasando como argumentos a esa query.
Exacto.
Entonces, de esta manera podemos hacer...
Pues ya podemos recuperar la ID de arcs.
Eso es.
Perfecto.
Muy bien.
Y ahora, ¿qué vamos a hacer?
Pues una query a la API REST como toca, ¿no?
Vale.
Creo, si no me equivoco, que añadiendole aquí directamente la ID recuperamos efectivamente la información.
Así que lo único que tendríamos que hacer, podríamos hacer esta función un poquito más lista, pero solo para hacerlo mucho más rápido.
Bueno, vamos a copiarla, le pasamos aquí la ID y aquí vamos a hacer esto, ahora lo convierto esto en un template string.
Y ojo, y ojo, que esto ya no es resolves, sino que esto es directamente todo lo que queremos pasar, voy a pasar esto así.
Bueno, no sé por qué me lo ha formateado así, le ha gustado más.
Pero queremos todo el JSON, ¿verdad?
Pero queremos todo el JSON, sí, ¿verdad?
Sí, tal cual.
Ahora, este fetch character es el que vamos a utilizar aquí en el resolver, de forma que esto devuelve fetch character y le pasamos la ID que nos llega.
¿Tiene buena pinta?
Tiene buena pinta.
Tiene buena pinta.
Vale, pues vamos al playground, voy a cerrar esto de aquí, le voy a dar al play y ahí tenemos, Morty Smith.
Vamos a intentar pegar más información.
¿Qué más?
Ay, es que ves como yo no soy un experto y Horacio sí, Horacio seguramente, yo volvía ya al código para ver cómo era el esquema y Horacio seguro que ha pensado.
No, lo tienen aquí.
Pero ¿por qué no le das a control, espacio, que te salen todos?
Es que, ¿cómo se nota?
No estamos acostumbrados a que nos ayuden tanto.
Sí, eso es lo que pasa.
Totalmente.
Mira, pues tenemos ID, Name y Status.
Y ahí lo tenemos.
Una cosa importante, en esta query el servidor está recibiendo toda la información de ese character.
Claro.
Pero ¿qué pasa?
Yo no puedo, por ejemplo, si vamos al esquema real del API REST.
Ah, del API REST, aquí.
Aquí.
¿Ves aquí, por ejemplo?
Si vas allí al resultado.
Aquí, aquí.
Sí, claro.
Aquí tenemos gender, aquí tenemos type, tenemos location, image.
Todas estas cosas no las podemos pedir.
Si tú vas a Playground, intentas pedir eso.
Por ejemplo, image.
Sí, image, por ejemplo.
Image, que seguro que no la he puesto.
Claro, yo pongo aquí image y me va a decir.
Image y te va a decir, ¿esto qué es?
Esto no sé qué es.
Aunque realmente lo está devolviendo la REST API, pero no podemos acceder a ellos si no le estamos indicando en el esquema.
No lo están definiendo, eso es.
Aunque tú tengas esa información, no lo puedes acceder, no puedes tener esa información porque no la has definido aquí.
Claro, tendríamos que definirla aquí, string, guardamos los cambios, volvemos aquí, le damos al Play y ahora sí podemos acceder al image.
Esto es importantísimo, por la validación de los tipos, para que los resultados sean predecibles, porque es que si no a la mínima se rompería todos los contratos.
A la mínima cambiarías aquí, ah, pues ya quiero image.
No, claro, tiene que pasar el esquema y validarse y esto es súper importante.
Es lo que le da la integridad a GraphQL, ¿no?
Y todo.
Me ha encantado.
Y hay alguna cosa que siempre sale y no sé si alguno estará pensando en eso, pero dice, wow, wow, wow, espera.
Entonces, ¿esto qué quiere decir? ¿Que estoy haciendo queries a lo loco a mi API REST?
¿Esto qué pasa? ¿Que no hay optimización? ¿No hay nada?
Sí que puedes llegar a hacer muchas optimizaciones y hay una herramienta que obviamente también da Apolo, que como no, que se llama Apolo Engine.
Si quieres podemos ir a la web.
Vamos a buscar.
Yo personalmente no la he utilizado.
Apolo Engine.
No la he utilizado, pero sí conozco gente que la ha utilizado y básicamente es como un ayuda a monitorizar tu API GraphQL.
Que además de que ve todo lo que se está haciendo el query, te ayuda también a ver dónde puedes hacer mejoras de optimización.
Oye, esta query a este resolver está demorando demasiado o no se está cacheando o cualquier cosa que tú veas en detrimento de performance te lo puede dar Apolo Engine.
Y es una herramienta muy interesante, es muy potente y simplemente con pasarle la URL, conectarlo y tal, ya tienes todo ese soporte.
Y está, es bastante bueno.
Y además esto es una llamada a una API REST, es como si lo hicieras desde un cliente.
Si tú tienes Redis, si tienes cualquier cosa en Varnish por en medio, no sé si conocen Varnish, pero son balanceadores de carga, tú puedes hacer un montón de optimizaciones aquí.
Claro, ¿no?
Porque tienes todo el control, todo el control.
Es que es brutal, a ver, es que esto es tan sencillo como incluso tener aquí una cache a nivel de Node que podríais, aunque sea un memory leak, pero aquí podríamos poner cache.
Hacer un objeto y evitar que hiciese siempre la petición o poner una LRU, ¿sabes? Para decir, bueno, solo que tenga mil.
Claro.
Tienes todo el control.
Tienes todo el control.
Y esto es una de las cosas que mucha gente, cuando decimos, no, que ahora el cliente tiene el control de pedir lo que quiera.
Sí, tiene el control de pedir lo que quiera, pero ves que en realidad en el server se define todo.
El server sigue definiéndolo todo.
Lo único que ahora ambos están siguiendo el mismo esquema, que es el que estás definiendo aquí.
Exacto.
Una cosa que yo creo que es importante que os quede clara, clarísima, es que pese a que vosotros en el playground estáis haciendo esta petición y cogéis el carácter y que solo tiene ID, Name, Image, Status.
Y como decía Horacio, claro, pensad que tenéis toda la información en la API.
Esto no va a hacer vuestra API más rápida.
Esto es súper importante porque sé que hay mucha gente que se cree, bueno, tenemos un problema en nuestra API, le matemos GraphQL.
Claro, podéis poner caché, todo lo que ha comentado Horacio, pero tened en cuenta que si vuestra API hace muchos cálculos, tiene que hacer muchas peticiones, la resta API que ya tenéis ya es lenta.
Esto en realidad, que vosotros cojáis menos campos, no importa.
Esto es solo como, digamos, otra capa que pones, ¿no?, para evitar que esto le llegue al frontend con tanta información que no necesitas o para hacer muchas más peticiones.
Pero tu API la tienes que optimizar para utilizarla lo mejor posible con GraphQL, por supuesto.
Sí que va a ayudar un poco en lo que vas a mandar por el wire porque obviamente está pidiendo más información.
Pero es lo que dices tú, o sea, la optimización que tienes que hacer en tu server y cómo accedes a realmente tu base de datos, eso no, GraphQL no le interesa.
Es más, es que a GraphQL no le importa dónde guardas la información.
Puedes en un API REST, en otra API GraphQL, en la base de datos, en local, da igual, no le interesa.
Él simplemente quiere saber, cuando alguien me pide esto, a dónde tengo que llamar, qué resolver tengo que hacer.
Exacto.
Olvídate, ya está.
Horacio, un verdadero placer. Me ha encantado. Muchísimas gracias por pasarte por aquí, por haber venido y habernos enseñado tanto con GraphQL.
Muchas gracias.
¿Dónde te pueden encontrar? Porque todo el mundo estará diciendo, este Horacio es un crack, este Horacio es un crack, lo quiero en mi equipo.
Bueno, yo soy freelance aquí en Barcelona, pero a estos cursos como el que hemos empezado a ver ahora, son sesiones de React GraphQL Academy, que bueno, estuvimos viendo al inicio.
Hacemos trainings en prácticamente bastantes zonas de Europa. Yo soy el único coach que está en Barcelona, así que si vas al Meetup, luego te paso el link.
Sí, sí.
Allí cada mes estoy intentando hacer una de las sesiones de nuestros cursos. Esta sesión, por ejemplo, en un par de días la haremos, pero seguramente estaremos haciendo muchas.
Todos relacionados sobre React y GraphQL. Y en Twitter también te van a pasar el Twitter y cualquier cosa.
Sí, ¿cuál es tu Twitter?
Ah, bueno, es un Twitter muy viejo. HHG2288.
Me encanta, me parece su password.
Exacto.
Vamos a probar si es tu password en todos los sitios.
Sí, ya te aviso, no lo es.
Es más corto.
Sí, es mucho más corto. Es un dos, tres, cuatro. No, mentira. Y cualquier pregunta que tengan, háganla allí en los comments. Intentaré seguir los comments. Y cualquier cosa que veas ahí, o sea, que no sé esto, dime. Y yo puedo ayudar allí en lo que pueda.
Darle like, compartirlo, darle cariño, porque así vamos a tener otra vez a Horacio aquí seguro y vamos a hacer cosas. Nos quedan pendientes las mutaciones.
Uy, que además me encanta el nombre de mutaciones. O sea, parece algo de Marvel o de X-Men.
Sí, y quizás hasta luego, si la cosa se pone más chula, hacemos hasta suscripciones, que es el otro tipo base de GraphQL, que esto ya entra con WebSockets y es un poco más complejo.
Darle like, darle like.
Pero eso es. Ya si les gusta, si quieren, pues podemos venir.
Bueno, muchas gracias a todos por seguirnos en esta serie de vídeos de GraphQL. Muchísimas gracias Horacio, una vez más. Ha sido un verdadero placer.
Miguel, me ha encantado. Suscríbete, dale like, comenta y nada, nos vemos en el siguiente. ¡Hasta luego!