Hoy vamos a terminar con fragmentos y suscripciones, que es por donde nos habíamos quedado.
Vimos en la última cómo iniciar sesión y cómo podíamos actualizar la caché de nuestro cliente de GraphQL con Apolo.
Vamos a poner el servidor. Voy a abrir el servidor de GraphQL, que lo teníamos por aquí.
Esto ya lo habíamos hecho. Hoy hay una cosita más.
Vamos a abrir el editor de nuestra aplicación de React, que tenía el Apolo Client con las conexiones de GraphQL y todo esto.
Esto lo vamos a levantar por aquí. Muy bien. Voy a levantar los servidores. Voy a levantar este, MPN Run.
Esto era un Start. Y esto lo que tenía era un Nodeemon y todo esto.
Se conectaba a MongoDB. O sea, es que hicimos la conexión de MongoDB y todo de GraphQL.
Y teníamos el Playground, donde podíamos ver cómo funcionaba todo. Perfecto.
Y esta era nuestra aplicación. Vamos a levantarla también. MPN Run Dev.
Y en el puerto 3000 teníamos nuestra aplicación de React. No es la aplicación más bonita que hemos hecho en el mundo,
pero es nuestra aplicación y la queremos tal y como es.
Muy bien. En la clase de hoy. En la clase de hoy vamos a ver fragmentos y suscripciones con GraphQL.
No te preocupes, que es bastante sencillo. Las suscripciones suelen ser un poco más problemáticas.
Vamos a ver cómo podemos utilizar fragmentos para evitar tener que repetir siempre que necesitemos extraer propiedades o atributos de algún esquema.
Como por ejemplo, cada vez que hacemos una query para buscar a una persona, siempre teníamos que decirle que queríamos sacar el nombre, el teléfono, la dirección, el street, el city.
Y teníamos que repetir constantemente lo que queríamos extraer de la persona.
Esto se puede hacer de una forma distinta, que sería utilizando más bien fragmentos.
Una cosa que se harían fragmentos. Pues vamos a ver cómo lo podemos hacer.
En el caso de los fragmentos, vamos a hacer este ejemplo rápidamente y lo vamos a hacer directamente en el cliente.
Porque los fragmentos se pueden poner en el servidor, pero no son tan útiles.
La gracia de los fragmentos es ponerlo directamente en el cliente.
Esto es diferente, como habíamos hecho antes, que habíamos puesto por un lado las queries y las mutaciones en el servidor,
pero los fragmentos se pueden poner directamente en el cliente.
Así que vamos a verlo, ¿vale? Vamos a ver cómo lo ponemos esto en el cliente en un momento y cómo nos puede ayudar a simplificar nuestro código.
Vamos a nuestro cliente. ¿Había abierto el editor? Sí.
Muy bien, perfecto. Pues vámonos a las queries.
Aquí en esta query, aquí tenemos el de todas personas y podemos ver que tenemos query, all persons, tenemos id, name, no sé qué, no sé cómo.
Lo que he dicho, ¿no? Que estamos repitiendo aquí todo el rato esto.
Pues además de query y mutation, que son los dos que hemos visto, tenemos otro que se llama fragment.
Que le puedes poner el nombre que tú quieras, por ejemplo, person details, y le tienes que decir sobre qué es este fragmento.
Pues le vamos a decir que es sobre persona, ¿vale?
Porque cuando nosotros hacemos una query de todas las personas, esto lo que nos devuelve es una persona.
Por lo tanto, cuando creamos un fragmento, le tenemos que decir sobre qué es lo que tiene que extraer esto.
Al final lo que tiene que extraer es exactamente lo mismo que hemos puesto aquí.
Así que todo esto que habíamos puesto aquí, lo podemos poner aquí, ¿vale?
Teníamos la id, el nombre y tal.
Y ahora esto vas a ver que es muy similar a cómo funcionan los objetos en JavaScript.
Muy similar.
En lugar de hacer esto, lo que hacemos, esto es hasta aquí, a ver que no la líe con las llaves, que si no luego esto cualquiera lo encuentra.
Vale.
Lo que tenemos que poner aquí ahora es utilizar un spread operator.
No es un spread operator al uso, ¿vale?
Porque no es exactamente eso.
Pero se ve exactamente igual con los tres puntos.
Esto es como cuando hacemos un spread de un objeto dentro de otro objeto y cosas así, ¿vale?
Que esparcimos las propiedades.
Pues esto es lo mismo.
Así que le decimos, este es el fragmento, tenemos person details y lo ponemos aquí.
Que tú ahora estarás preguntándote, bueno, pero esto tampoco me ayuda mucho.
Bueno, luego verás cuál es la gracia de esto.
Porque ahora lo estamos poniendo aquí junto a la query.
Esto es obligatorio, ¿vale?
Ponerlo junto a la query para que sepa a qué fragmento te estás refiriendo.
Pero luego veremos cómo podemos mejorar esto como para simplificar mejor este, para ver mejor este código, ¿vale?
Una vez que has hecho esto, si vamos a nuestra aplicación, pues esta aplicación debería funcionar exactamente igual,
extraer exactamente los mismos datos y ya estaría, ¿vale?
Pero vamos a ver cómo podemos darle una vuelta de hoja a esto.
Porque si vamos a mutations, ¿vale?
Podemos ver que aquí también podría utilizar ese fragmento, ¿cierto?
Vale, pues lo que vamos a hacer es, igual que tenemos aquí en la query, estamos exportando la constante all persons,
lo que podríamos hacer aquí es exportar también la constante person details fragment.
Entonces, utilizamos gql, ¿vale?
Para el lenguaje que hay que poner ahí para el string, lo ponemos aquí.
Y ahora lo que podemos hacer es que dentro del all persons, pues vamos a evaluar el person details fragment.
Así, este string que tenemos aquí, pues también lo tendríamos aquí disponible y ya podríamos utilizar el person details, ¿vale?
Esta podría ser una forma de utilizar o reutilizar los fragments.
Así ahora en la mutation, igual, lo que podemos hacer aquí es que en lugar de utilizar todo esto, ¿no?
Que nos devuelva todo esto, como siempre estábamos con lo mismo,
lo que podríamos hacer sería evaluar también el person details fragment.
Y ves que en cuanto lo he puesto aquí y le he dado al enter, pues me lo ha importado automáticamente y ya lo tendríamos.
Ahora este fragment lo podríamos reutilizar en más de un sitio, que tiene todo sentido del mundo.
Bueno, una cosa importante, esto no va aquí, que esto lo he puesto yo aquí porque no, esto va abajo, ¿vale?
Esto va abajo.
Lo que tenemos que poner aquí, importante, ¿ves?
Yo ya la iba a liar, es lo de los tres puntos y decir el fragment, ¿vale?
Esto es que quiero esparcir todas las propiedades que extrae el fragment.
No es que como lo he puesto yo aquí, que lo he puesto aquí dentro y ya está.
Esto es como lo hacíamos aquí, básicamente, ¿vale?
Con el fragment, pues lo que hacemos es, aquí estaríamos copiando el fragment, ¿vale?
Tendríamos esto aquí, pero lo estamos haciendo así para poder reutilizarlo.
Y aquí le decimos cómo tiene que esparcir todas las propiedades del fragment que queremos utilizar.
Y con la mutación sería lo mismo, ¿vale?
O sea, tenemos que evaluar aquí el fragment, justo debajo de la mutation.
Y aquí es donde le decimos que tienes que esparcir todas las propiedades que estás extrayendo del tipo del esquema persona, ¿vale?
Esto sería como funciona.
Así que lo podemos utilizar en más de una query, por ejemplo.
Podemos tener diferentes fragments.
Por ejemplo, ¿veis aquí que pone name, id, font?
Si esto puede ser útil, porque si tenéis un montón de fragments, esto sea person,
esto más que details podría ser all details, ¿vale?
Y tener todos los detalles así.
¿Por qué puede ser útil esto?
¿Por qué puede ser útil esto?
Porque pensad que si vosotros tenéis esto todo el rato repetido a lo largo de vuestro código, ¿vale?
En todas las queries, en todas las mutaciones.
Y esto es lo que serían todos los detalles de una persona.
Imaginad qué pasa cuando un día le añadís un solo atributo.
O sea, un solo atributo.
En lugar de id, name, font y le ponéis age.
Pues esto lo que hace es que tengáis que ir a través de todas las queries y todas las mutaciones
para añadir manualmente, si te interesa, que normalmente será que sí que te interesa,
para añadir manualmente esta propiedad que ahora también tienes que traerte.
Entonces, por eso normalmente los fragments, aparte de que es obvio que cuanto más difícil,
¿veis?
Aquí tenemos address, stretch city, pero esto puede empezar a ir creciendo, ¿sabes?
Puedes tener postal y aquí pues más cosas.
O sea, además de evitar estar duplicando o triplicando código y de simplificarlo,
además está eso, ¿vale?
Es la mantenibilidad de tu código a lo largo del tiempo.
Porque los esquemas pueden ir cambiando y de esta forma digamos que lo que estás haciendo
es como describir partes de la información que quieres extraer en un solo sitio.
Así que puede ser una buena práctica, pese a que ahora mismo a veces no le veas el sentido
porque digas, bueno, tampoco me va a evitar muchísimo código o lo que sea, ¿vale?
Pero pese a ello, ay, pues mira, la he liado, que he hecho algo.
Vale, espérate, es que como le he cambiado el nombre, no se lo he cambiado bien en todos los sitios,
¿vale?
Esto por aquí, esto por aquí.
A ver ahora, sí.
Pues aunque ahora no le veas el sentido, ten en cuenta eso, ¿vale?
Que si tienes que cuidar de una aplicación que tenga que ir evolucionando, pues esto te puede ayudar.
Esto sería el tema de los fragments, que ya hemos visto que es súper sencillo, ¿ok?
No es muy complejo.
Vamos con otro tema.
Ahora, que este sí que es súper interesante, o al menos a mí me parece muy interesante.
Es el tema de las suscripciones, ¿no?
Tenemos ya consultas, tenemos mutaciones y eso lo podemos ver justamente en el servidor.
Vámonos al server.
Mira, voy a hacer una cosa que esto me gusta mucho, que es mover, mostrar, no, ¿cómo es?
Merge all windows.
Bueno, este truquillo me gusta y no sé por qué no lo hago más.
Vale, así puedo cambiar fácilmente entre una y otra.
Vale.
Esto sería el servidor, ¿no?
Y en el servidor, pues aparte de nums, que vimos lo que eran los tipos, que justamente como para las type definitions,
para describir todo nuestro esquema, tenemos las queries y tenemos las mutaciones.
Bueno, pues hay más, hay más.
Hay un tema que se llaman suscripciones, que como dice el nombre, lo que te permite es suscribirte a cambios que puedan ocurrir justamente en tu esquema a la hora de añadir, pues, nuevo dato, cambiar un nuevo dato, cuando ocurra cualquier cosa.
Tú te puedes suscribir.
Bueno, hasta ahora todas las interacciones que hemos visto han sido utilizando HTTP.
De hecho, si vamos aquí a la network, pues esto es HTTP y aquí podemos hacer, pues son como peticiones puntuales, ¿no?
En las que dices, dame información, guarda información.
Y son momentos puntuales.
Vimos que podríamos hacer el refresh o el polling, ¿no?
Que sería el tema de ir preguntando cada X segundo, pero una suscripción no funciona como una petición HTTP, sino que lo que hace es quedarse suscrito, ¿no?
Y lo que te levanta es un WebSocket en la que va a estar escuchando constantemente y cuando ocurre algo, pues va a estar informado, ¿vale?
Se va a suscribir y podrá hacer cosas cuando esto ocurra.
Para poder utilizar una suscripción, lo primero que tienes que hacer, lo primero, como siempre, es pasar por el servidor.
Y de la misma forma que dijimos que teníamos type query, type mutation, pues ya te puedes imaginar que también tenemos type subscription, ¿vale?
Y en el tipo de la suscripción le tenemos que decir las suscripciones que tenemos.
En este caso, vamos a hacer un ejemplo de tener una suscripción que nos va a decir cada vez que se añada una persona.
Cada vez que nosotros utilizamos la mutación de añadir persona, que le pasamos el nombre, el font, el street y tal, lo que vamos a hacer es tener una suscripción que cada vez que ocurra esto, pues vamos a poder suscribirnos y poder recuperar la persona que se ha añadido, ¿vale?
Así que lo primero, importante, poner la definición del tipo.
Ahora tenemos que importar cositas.
Lo primero que tenemos que importar por aquí sería PupSup, ¿vale?
PupSup, básicamente que es de publicar y suscribir.
Es un sistema en el que tú te suscribes a algo y publicas eventos para saber exactamente qué es lo que está ocurriendo, ¿vale?
Esto es una clase en la que al final podemos crear una instancia, PupSup,
y esta clase es la que nos va a permitir crear estos eventos y suscribirnos a ellos para poder hacer cositas.
¿Dónde queremos que esto ocurra?
A ver, podemos primero crear en los resolvers, vamos a necesitar un resolver para nuestra suscripción.
¿Ves? Tenemos todas las de las queries, tenemos todas las de la mutación.
Vamos a ver ahora cómo podríamos utilizar el PupSup para lo que queremos, ¿vale?
Voy a dejarla aquí abajo.
Vamos a ver subscription, subscription, subscription, no en plural, subscription.
El objeto de subscription es un poco diferente a cómo eran las queries, mutation y tal, ¿no?
En la query teníamos personCount, que esta era la query que nosotros teníamos que hacer,
y esto ya era un método tal cual.
Aquí es un poco diferente.
Sí que tenemos que poner el personAdded, ¿vale?
Como lo hemos puesto en la definición del tipo,
pero aquí lo que tenemos es un objeto que le tenemos que pasar una propiedad que es subscribe.
Y es aquí donde tiene el método, que es cómo va a ocurrir esta suscripción.
¿Cómo va a ser?
Pues lo que va a hacer es utilizando PupSup, va a utilizar una syncIterator, ¿vale?
Y le vamos a decir cuál es el evento que tiene que suscribirse y que es totalmente asíncrono.
Pues en este caso es PersonAdded.
Este nombre ya verás que es arbitrario.
Tú podrías poner lo que te dé la gana.
O sea, PersonAdded o NewPerson, lo que sea.
O AddedEvent o lo que tú quieras, ¿vale?
Este string es que yo lo he seleccionado así, pero tú lo puedes poner como tú prefieras.
De hecho, ahora vas a ver por qué es que lo puedes poner como tú quieras.
No es que tenga que ser este.
No es como normalmente hemos visto PersonAdded.
Este sí que tiene que ser exactamente el mismo nombre que hemos puesto en la definición del tipo.
Pero este string no, no importa.
De hecho, esto lo vamos a utilizar en la mutación del AddPerson.
De la misma forma que en la suscripción estamos haciendo un PupSup para suscribirse a cada vez que le llegue un PersonAdded, ¿no?
Con la información que sea, ¿vale?
Y devuelva la información que le está llegando.
Esto lo que hará es devolver la persona.
Le tenemos que pasar la persona.
¿Y cuándo ocurre esto?
Pues lo que tenemos que hacer es buscar la mutación de AddPerson, ¿vale?
Que es justamente esta.
Cada vez que añadimos una persona, antes de devolver una persona, lo que vamos a hacer aquí es utilizar el PupSup.
Y vamos a decirle, vale, PupSup publica un evento.
¿Qué evento?
Pues el PersonAdded.
Por eso te decía que puede ser el nombre que tú quieras.
Lo importante es que sea el mismo aquí y abajo.
Pues te tienes que estar refiriendo al mismo evento.
De hecho, sobre esto ahora te explicaré una cosa.
Al menos que a mí no me gusta especialmente utilizar strings como contratos de este tipo.
Y ahora lo arreglaremos.
Y ahora le pasamos un objeto con la información que necesita.
Pues sería PersonAdded y le pasaríamos la persona.
Así que sería un objeto, PersonAdded y la persona.
Que la persona es la misma que íbamos a devolver.
Y con esto estaríamos creando ya una suscripción.
Esto lo puedes hacer para lo que tú quieras.
Pero ya ves que tienes, digamos que...
A ver, es manual, obvio.
Pero eres tú quien tienes que indicarle justamente dónde tienes que causar esta publicación de la suscripción.
Y dónde te tienes que suscribir.
No es que sea difícil.
Pero ya ves que lo tienes que hacer manualmente.
¿Vale?
Entonces...
Ah, esto del string.
Yo personalmente a mí esto que utilizar un string y de esa forma no me gusta mucho.
Normalmente puede estar bien o...
Subscription Events puede ser, ¿no?
Pues aquí pues lo típico.
PersonAdded.
Y aquí pues le podéis poner o el mismo.
Que es lo típico, ¿no?
De ponerle el mismo.
Y si cambia este string pues no pasa nada.
O le podéis incluso poner...
Podríais ponerle números.
Lo que queráis.
¿Vale?
Y de esta forma ya no utilizáis el string directamente.
Y os aseguráis de que siempre va a funcionar correctamente.
Esto con TepScript pues veremos que tampoco pasa nada.
Porque suele ser mejor.
El hecho de poder utilizar en OMS.
Pero bueno.
¿Y dónde habíamos puesto este?
Aquí.
¿Vale?
Y ya no veis un string.
Porque es que los strings te puedes equivocar manualmente.
Lo que sea.
Ahora que tenemos la suscripción puesta.
Vamos a cambiar aquí una cosita.
En el server.listen.
Que es como para iniciar el servidor.
Lo que vamos a hacer aquí.
Es que aparte de escuchar la URL.
Podemos escuchar la URL también de los WebSockets.
Porque como os digo.
Hasta ahora estamos utilizando HTTP.
Pero HTTP para este tema de suscripciones.
No suele ser muy eficiente.
Y se suele utilizar WebSockets.
Que bueno.
Cada uno tiene sus ventajas y sus desventajas.
Pero en el caso de estar haciendo este tipo de escucha activa.
Normalmente se utilizan con WebSockets.
Así que tenemos una subscriptions URL.
Mira.
De hecho hoy me lo está diciendo.
Me lo está chivando.
Y vamos a poner console.log.
Para poner subscriptions ready add.
Y vamos a poner el subscriptions URL.
¿Vale?
Y de esta forma pues veremos.
Si está funcionando bien o no.
Vamos al servidor.
Vale.
Nos dice.
Subscription ready add.
¿Ves?
WebSockets.
Bueno.
WebSockets.
Dos puntos.
Barra barra.
Localhost.
4000.
Barra.
GraphQL.
La dirección es exactamente la misma.
Pero el protocolo es lo que es distinto.
Esto ya lo podríamos probar.
Sin necesidad de hacer nada más en el cliente.
Y así pues vamos a ver si esto funciona bien.
Esto es el playground.
Que espero que lo hayas visto en clases anteriores.
Podemos aquí utilizar todas las queries.
Lo que haga falta.
Una de las cosas que podemos hacer era loggearnos.
Iniciar sesión.
Y también añadir una persona con la información que queramos.
Ahora hemos creado una nueva.
Podemos poner aquí subscription.
Subscription.
O como sea.
Nos suscribimos a la person added.
¿Vale?
Y cuando tenemos la persona added.
Aquí como tenemos una persona.
Pondríamos name.
Phone.
Address.
Lo que tú quieras.
Vamos a poner name.
Name.
Por ejemplo.
¿Vale?
Una vez que le deis aquí.
Fíjate que lo que hace es que se queda en listening.
Se queda ya.
Se suscribe.
Está genial esto de que lo puedas hacer ya en el playground.
Porque entonces ya puedes probar aquí la suscripción.
Y olvidarte de si aquí funciona.
Debería funcionar en cualquier sitio.
De nuevo.
Aquí podéis poner lo que queráis.
Pues el phone.
La id.
Podéis poner los campos que queráis.
Y estos sean los campos que iréis recibiendo.
Vamos a darle al play.
Esto se queda escuchando.
Pero para añadir una persona teníamos que utilizar un token.
Así que voy a iniciar sesión.
Esto me devolvió a este token.
¿Vale?
Y ahora utilizando la mutación de addperson.
Vamos a utilizar aquí nuestro token.
¿Vale?
Fuera.
Tira para allá.
Vale.
Perfecto.
Y ahora.
Bueno.
Aquí podríamos poner.
Voy a buscar en el chat.
Vamos a buscar en el chat.
A ver quién.
Hay gente que me dice ahora buenos días.
Buenas tardes.
Magnus Go.
Venga.
Magnus Go.
Te ha tocado.
Magnus Go 7.
Magnus Go 7.
1, 2, 3.
Que viene además.
Magnus Go.
Dice.
Tendrás algún curso sobre esto publicado.
Calle publicado.
Y ciudad curso.
¿Vale?
Vale.
Pues con esto vamos a hacer la mutación de añadir la persona.
Vamos a darle al play.
Aquí parece que se ha añadido correctamente la persona.
Si nos vamos a la suscripción.
Vemos que nos ha devuelto esta información.
En data person added.
Tenemos el nombre.
El font y id de la persona que hemos añadido.
Y no hemos hecho absolutamente nada.
O sea.
Nos hemos suscrito.
Vamos a añadir otra persona.
Venga.
Gorusuke quiere añadir.
Creo que Gorusuke ya está.
Gorusuke.
Vamos a probar.
Si no petará.
Y ya está.
Que dice.
Aquí.
Y la ciudad.
Creo que es Colombia.
No sé si es Bogotá o Colombia.
Lo que sea.
Lo añadimos.
¿Vale?
Pam.
¿Ves?
Gorusuke ya está.
Y por lo tanto peta.
Y por eso aquí.
De la suscripción nada.
Dijimos que el nombre tenía que ser único.
Por lo tanto.
Si Gorusuke ya existe.
Pues ya está.
Y ahora tenemos Apocalipsus 9.
9.
9.
Venga.
Este seguro que no está.
Le doy a play.
Hemos añadido Apocalipsus.
Me voy a person added.
Y otro.
¿Vale?
Y fíjate.
Aquí no aparece.
Porque pone.
No sé si un minuto hago.
Beta sabe lo que pone ahí.
Pero el tema es que.
Al estar suscritos.
Cada X tiempo.
¿No?
Que vaya saliendo aquí.
Pues vamos a ir viendo los diferentes que nos van llegando.
¿Vale?
Esta sería la suscripción.
Venga.
Elena.
De Argentina.
Street.
Vamos a poner Gozalez.
Y vamos a poner Argentina.
¿Vale?
Venga.
Y ya.
Con esto ya lo dejamos aquí.
¿Vale?
Bueno.
Está abajo.
Ahora que lo pienso.
No sé por qué.
Es verdad.
Esto es súper raro.
¿Veis que no aparece?
En realidad no es que no aparezca.
Es que.
Tiene un fallo.
El scroll.
Hay un fallo en el scroll.
Si miro.
Si miramos aquí.
Y lo inspecciono.
Aparece Elena.
Pero.
Es súper raro.
¿Vale?
No sé por qué.
Tiene algún problema de.
Aquí.
Este scroll.
Solo tiene los scrolls.
De los que ha aparecido aquí.
Es súper raro.
Pero si miramos los elementos.
Está.
Si no.
No pasa nada.
Porque lo vamos a ver aquí.
En nuestra aplicación.
De hecho.
¿Ves?
Ahora Elena está por aquí.
O sea.
Ha funcionado correctamente.
Pero el playground este.
Tiene un problema de esto.
La suscripción ha funcionado.
Que es lo importante.
¿Vale?
Muy bien.
Vamos a ver.
¿Qué más?
Ya tenemos la suscripción.
Hemos visto que funciona en nuestro playground.
Pero obviamente.
Lo interesante.
Es ver las suscripciones en el cliente.
¿No?
Lo que nos interesaría.
Sería verlo en el cliente.
Bueno.
Quédate conmigo.
Porque en el cliente tiene un poquito de miga.
Tiene un poquito de cosa.
Pero vamos a ir paso a paso.
Y te aseguro que lo vas a entender.
Vamos.
O sea.
Es que si no.
Te devuelvo el dinero.
En la suscripción no.
Porque eso ya lo tienes.
Twitch.
Vamos paso a paso.
Venga.
¿Qué hay que hacer para poder suscribirse en el cliente?
A este WebSocket que hemos creado.
Porque en el playground hemos visto que esto está tirado.
Súper fácil.
Bueno.
Pues en el cliente.
Es fácil.
Pero no está tan tan tan tirado.
Vamos a ir paso a paso.
Y lo vas a ver.
Lo primero que hay que hacer.
Y esto es un tema que necesita Apolo Client.
Igual hay otro cliente que no lo necesita así.
Lo primero que tienes que hacer es instalar una dependencia.
Que se llama subscriptions-transport-ws.
WebSocket.
Esta es una dependencia que necesita Apolo Client para funcionar con WebSockets.
Así que la instalamos.
Esto lo tiene en la documentación.
Lo tiene bien explicado.
Y ya está.
Una vez que ya lo tenemos instalado.
Ya podemos ir a nuestra aplicación.
Nos vamos aquí a la aplicación de React GraphQL.
Vamos a ir a main.jsx.
Porque es aquí donde estamos haciendo todo el tema del HTTP link.
El outlink.
Todo esto.
¿Vale?
Te hago un repaso rápido para que más o menos te suene.
Pero aquí este es el punto de entrada como de nuestra aplicación.
Y teníamos.
Creamos el enlace HTTP hacia nuestro servidor de GraphQL.
Y nuestro outlink.
¿Para qué necesitamos el outlink?
Porque dependiendo de algunas queries.
Lo que teníamos que hacer justamente era añadir el token.
¿Vale?
El de autenticación que yo he añadido aquí manualmente.
Aquí en el addPerson yo he añadido esto.
Lo he añadido manualmente.
Para que sea automático.
Nosotros teníamos este outlink.
Que lo que hacía era pasar un objeto headers.
Teníamos authorization.
Y recuperamos el token del local storage para que pudiera el usuario, una vez que había iniciado sesión, poder hacer ciertas operaciones.
Así que en el cliente, para crear el Apollo Client cliente, teníamos lo de DevTools a True.
¿Vale?
Esto era lo que vimos en las Developer Tools.
La caché.
Esta también era obligatoria.
Que por ahora era memoria.
Y el link.
Que link tienes que entender como un enlace hacia el servidor.
Donde tienes que recuperar los datos.
A los que quieres que el cliente se conecte.
¿Vale?
Entonces, estamos utilizando como el outlink y el HTTP link.
Estamos utilizando estos dos de aquí.
¿Vale?
Esto sería todo.
Luego aquí, bueno, pues nuestra aplicación de React con el provider.
Que se pasa al cliente.
Y tal.
Hasta aquí.
Todo perfecto.
Todo entendible.
Así que necesitamos otro enlace.
Otro link.
Tenemos el HTTP.
Tenemos el de out.
Vamos a crear uno más.
Lo voy a crear aquí abajo.
¿Cuál es el que necesitamos crear?
Pues necesitamos crear uno que le llamamos WS link.
¿Vale?
Como WebSocket link.
Y vamos a crearlo.
Pero necesitamos importarlo.
Que es el de WebSocket link.
Esto es una cosa que ya viene directamente de la propia librería de Apolo.
¿Vale?
WebSocket link.
Pensaba que me iba a salir.
A ver.
WebSocket.
Pensaba que iba a salir WebSocket link al importarlo manualmente.
Pero bueno.
Si no, no pasa nada.
Porque esto es import from Apolo.
Client barra link barra WS.
¿Veis?
Que está aquí.
Y ahora aquí tendríamos que WebSocket link.
¿Veis?
Es raro que normalmente lo detecta bien.
Pero bueno.
Pues este sería.
¿Vale?
Tenemos que crear un enlace con el WebSocket.
Ahora le tenemos que pasar por la información que necesite.
Por un lado, la URI.
¿Vale?
La URI es como la URL o la dirección donde tenemos esto.
Esta es justamente lo que teníamos antes.
Si vamos a nuestro servidor.
¿Veis que teníamos esto?
Pues esto nos lo copiamos y lo pegamos aquí.
Y ya tendríamos nuestra URI.
Ahora le puedes pasar opciones.
Options.
Hay una que está bien que es la de Reconnect.
¿Vale?
Por si, por lo que sea, pues se cierra, ¿no?
Porque si estás en tu aplicación, dependiendo mucho de este tipo de suscripciones, si por
lo que sea se cae esa conexión, pues lo que vas a querer es que se reconecte lo antes
posible para que no notes que ha habido ningún problema.
Porque si no, podrías perder las suscripciones y, hombre, puede ser un problemilla.
¿Vale?
Luego ya tenemos el link.
O sea, es esto.
Este WebSocket link, este enlace es este.
¿Qué pasa?
Que tú ahora sí que podríamos hacer que todas las peticiones pasasen por este enlace
del WebSocket link.
Pero ocurre una cosa.
Los WebSockets están muy bien para un caso de uso en concreto.
Normalmente, aunque podríamos hacer que todas las operaciones pasasen por aquí, es
mucho más óptimo, eficiente y escalable que lo que son queries y mutaciones pasen por
el HTTP y lo que son suscripciones pasen solo por el WebSocket link.
Por lo tanto, lo que tenemos que hacer es hacer como un split, ¿vale?
Tenemos que detectar cada una de las operaciones y llevarlo a un link diferente.
Y eso es lo que vamos a hacer, ¿vale?
Vamos a hacer un split, vamos a ver qué operación es la que queremos hacer y dependiendo de esa
operación vamos a utilizar un enlace u otro, ¿ok?
Así que, de esta forma, seguiremos utilizando HTTP para lo que nos interesa.
Esto lo soporta Apollo Client, ¿vale?
Esto no es una cosa que, bueno, es un poco rara, pero es una cosa que Apollo, de hecho,
te recomienda hacer en este tipo de casos.
Por eso te da un método que se llama split y lo vamos a ver ahora cómo se utiliza, ¿vale?
Con este método split lo que tenemos que hacer es crear otro link, ¿vale?
Le voy a llamar split link.
Este split link al final es eso, es el que va a decidir qué link vas a utilizar.
En un caso u otro.
Por eso, split, esto lo que tiene, ves, son tres parámetros.
Uno que se llama test, que ahora veremos lo que hace, luego left y luego right.
Es que split es básicamente eso, ¿no?
Te llega una operación y dependiendo de eso, pues lo llevas a un lado o lo llevas a otro.
Así que, el primer parámetro, que es el test, es una función que es la que va a determinar
si tiene que ir a la izquierda o a la derecha.
Si devuelve true, el primer parámetro, la función que le vamos a pasar, ir a la izquierda.
Si es false, ir a la derecha, ¿vale?
Entonces, a la izquierda tenemos un link y a la derecha tendremos otro link.
Esto, total, no se suele hacer mucho, pero sí que se suele hacer mucho para el tema de las suscripciones,
como vamos a ver ahora mismo.
Así que, tenemos el split, que es una función.
Ahora voy a hacer esa función.
Si da true, vamos a hacer que vaya al link de los websockets.
Si da false, le vamos a decir que vaya al que estamos utilizando antes, que es el outlink.cat.
Todo esto, ¿vale?
Y ahora el que queremos utilizar es el split link.
Pero, todavía nos falta la función esta, que es la que hace la magia, ¿no?
De devolver true o false, dependiendo de una cosa u otra.
Esta función nos va a llegar la query que se ha hecho, ¿vale?
Este split link, todas las operaciones que estamos haciendo en GraphQL,
mutaciones, queries, suscripciones, todo, va a pasar por aquí antes,
porque es el que necesitamos para decidir si tiene que ir a un sitio u otro.
Pues, con la query, lo que podemos hacer es ver, justamente, la definición, ¿vale?
Vamos a poder leer la definición, ver toda la información que tiene,
qué tipo de operación es, si la operación es de un tipo en concreto,
si es una suscripción, una mutación, lo que sea.
Para poder leer esto, necesitamos el método getMainDefinition, este de aquí, ¿veis?
Que esto lo va a importar también del Apollo Client.
GetMainDefinition y le pasamos la query.
El GetMainDefinition, ¿veis?
Me la tengo que importar aquí, bueno, automáticamente.
Vale, ¿ahora qué tenemos la definición?
Pues ya está, o sea, es que ya está, es que tampoco es para tanto,
lo que pasa es que quiero que os quede muy claro por qué se hacen las cosas.
Entonces, lo único que tenemos que hacer es devolver algo.
Y lo que tenemos que devolver es que si la definición, el tipo de esto es OperationDefinition
y, además, el Definition.Operation es del tipo subscription, ¿vale?
Entonces, es true, ¿vale?
Y si es true, pues es lo que hemos dicho, justamente, ¿no?
Voy a ponerlo así.
No sé si lo voy a dejar así.
Mejor, creo que se lee mejor así.
Vale.
Si es una OperationDefinition y la operación que se hace es la de la suscripción,
entonces utiliza el WebSocketLink.
Si no, seguirá yendo donde iba antes, ¿vale?
Así de sencillo, así de fácil.
Y ahora, este nuevo link, SplitLink, que hemos creado, lo tenemos aquí.
El link, SplitLink.
A ver, esto es una cosa que hay que saber una vez y ya está.
Tampoco es que hace falta que te quedes ahí, ah, y todo loco.
Esto es lo bueno, ¿no?
De alguna forma, el Apollo Server te está haciendo WebSockets totalmente gratis.
No has tenido que configurar absolutamente nada.
Pero a la hora de consumirlo, para consumirlo de la forma más óptima,
esto es lo mejor que puedes hacer, ¿vale?
Hacer este Split.
Pero esto, una vez que lo haces, pues te olvidas para siempre, por siempre y ya está.
Voy a guardar los cambios.
Voy a ver que no haya roto nada en mi aplicación.
Todo parece funcionar bien.
Así que entiendo que se sigan haciendo las peticiones, ¿ves?
Con el HTTP Protocol y tal.
Pero todavía no estoy utilizando esta suscripción.
Vamos a utilizarla.
¿Cómo podemos hacer esto?
Pues vámonos aquí.
Vamos a crear, ya que estamos haciendo esto con mutations, queries y tal,
pues voy a crear aquí un GraphQL subscriptions.js.
¿Vale?
Vamos a importar el GQL de Apollo Client, que esto es lo que nos va a permitir.
Export const person added GQL.
Y aquí podríamos pegar la suscripción.
Bueno, pues es subscription.
Y este es el person added.
Vamos a poner aquí el id, el name, el font, el address, street y city.
¿Vale?
O sea, una suscripción que queremos que nos devuelva a todos los campos.
Ahora que ya tenemos esto, guardamos los cambios y vamos a ver dónde utilizamos esta suscripción.
Voy a ir cerrando todo.
Y ahora mismo, y es que esto es muy interesante.
Pero bueno, lo voy a utilizar en el app.js, ¿vale?
En el punto de entrada de nuestra aplicación.
Y aquí podremos importar, igual que teníamos el, ¿ves?
Use Apollo Client, teníamos el Use Query, Use Mutation.
Pues obviamente ahora tenemos un Use Subscription, ¿vale?
Y este es el que vamos a utilizar.
Con este Use Subscription lo vamos a poner aquí en medio.
Y vamos a decirle, ¿qué suscripción es la que quieres utilizar?
Pues es la de person added.
Que no me ha detectado, pero es la que acabo de crear aquí.
¿No?
Person added.
Así que la importamos.
Aquí.
From.persons.graphql.suscriptions.
¿Vale?
Nos vamos a suscribir a esa.
Y una vez que tengamos algún tipo de información sobre esto,
ahora le podemos pasar aquí un objeto con diferente,
tiene diferente configuración aquí.
Si miramos, esta es la que nos interesa.
OnSuscriptionData, ¿vale?
Cada vez que esta suscripción nos dé datos, queremos hacer algo.
Así que, bueno, obviamente, si queremos hacer algo,
siempre tenemos que pasarle una función, no falla.
Así que en esta función nos va a devolver el SubscriptionData.
Es una maravilla.
¿Veis?
Esto es lo bueno de TypeScript.
Esto, al tener TypeScript, pues es que nos va chivando el nombre de las propiedades y todo esto.
Aquí vamos a tener SubscriptionData.
Vamos a hacer una cosa.
Voy a hacer un ConsoleLog de SubscriptionData para ver qué tiene.
Aunque ya os digo yo que va a ser algo así.
Person.
Esto va a ser SubscriptionData.data.personadded.
¿Vale?
Esto va a ser algo así.
De hecho, podríamos hacer algo así.
Y esto lo voy a poner así para que nos salga un objeto.
Yo creo que es así.
SubscriptionData.data.addedperson.
¿Vale?
Creo que es así.
Pero voy a dejar el ConsoleLog.
Y ahora sí lo probamos.
A ver qué...
A ver si funciona.
Voy a volver a hacer esto.
Por ahora parece que funciona bien.
¿Ok?
No sé.
No sé si deberíamos ver ya la conexión aquí.
A ver.
Localhost.
Mira.
Aquí tenemos...
Este es el punto JS.
¿Vale?
Localhost.
Mira.
Aquí tenemos el WebSocket.
¿Veis?
Que tenemos aquí un WebSocket.
Pues aquí ya tenemos la conexión.
Así que...
Mira.
SwitchingProtocols.
Ya tenemos ahí un WebSocket.
Se supone que debería estar funcionando como esperábamos.
Pues vamos a ver.
Vamos a intentar hacer un cambio aquí.
A ver si nos devuelve en algún momento.
Uy.
Le he dado algún botón.
A ver si vemos aquí en la consola que nos devuelva la suscripción.
¿No?
Este ConsoleLog.
SubscriptionData.
Vamos a ver.
Vamos a ver a alguien del chat.
Vamos a poner...
SwapUruguay.
SwapUruguay.
Con el teléfono...
La calle...
Y la ciudad de Uruguay.
Bueno.
Ciudad de Uruguay que no existe.
Pero bueno.
Añadimos la persona.
¿Vale?
Han pasado unas cuantas cosas porque también estábamos actualizando la caché.
Pero lo importante es este.
¿Vale?
¿Veis que aquí sale ahora ya SwapUruguay?
Pero aquí está lo importante.
SubscriptionData.
O sea que sí que se ha ejecutado esto.
SubscriptionData.
Tenemos Data.
PersonAded.
Y aquí tenemos toda la información de la personita.
IDName.
O sea ya tenemos una forma de suscribirnos.
¿Vale?
En la parte del cliente.
Así que ya podemos hacer cosas.
Que es lo que necesitábamos justamente.
Así que perfecto.
Perfecto.
Ya hemos pasado un puntito más.
Un puntito más.
¿Qué podemos hacer con esta suscripción?
¿Y qué es lo que yo recomendaría?
Si recordamos cómo he hecho.
Cómo hicimos juntos.
Tú y yo.
Bueno.
Todos ustedes y yo.
El hecho de poder reflejar los cambios en la UI.
¿Cómo lo hicimos?
Lo que hicimos.
Había diferente forma.
Vimos lo de Refetch.
¿Vale?
Eso lo vimos en una clase.
Vimos actualizar la caché.
Que esto es lo último que hicimos.
Y lo tenemos aquí.
¿Vale?
Esto es una forma.
¿Vale?
De actualizar la caché.
Lo que hicimos es que vale.
Creando la mutación.
Utilizando esa mutación.
Manualmente actualizamos la caché.
Así que cada vez que se actualizaba.
Pues mirábamos la caché.
Actualizamos la caché.
Y como esta caché es como un estado global.
Que está utilizando nuestra aplicación.
Para pintarse.
Cuando se detecta ese cambio en estado global.
Pues aparece aquí.
¿Vale?
Estamos escribiendo la caché.
Y se refleja el cambio.
Esto no está mal.
Y de hecho se podría quedar así.
Y podríamos olvidarnos totalmente de las suscripciones.
Pero como estamos utilizando suscripciones.
Te voy a decir.
Como yo.
Creo que ya.
Una vez que ya tenemos suscripciones.
Deberíamos hacer esto.
Yo me olvidaría.
De actualizar la caché.
Manualmente.
¿Por qué?
Porque aunque es verdad.
Que este componente visual.
Está añadiendo una persona.
¿Quién te dice a ti?
Que no se puede añadir una persona.
Desde diferentes puntos.
De la aplicación.
O sea.
Se puede estar añadiendo una persona.
Desde un montón de sitios.
El problema que tenemos aquí.
Es que estamos acoplados.
A que se añada aquí.
Imagínate.
Que tenemos una aplicación de móvil.
Y en la aplicación de móvil.
También se puede añadir una persona.
Lo bueno de la suscripción.
Es que nos estamos suscribiendo.
Independientemente.
De donde ocurra.
Ese cambio.
En cambio aquí.
Lo que tenemos.
Es el código.
Aquí.
Que es cuando ocurre aquí.
Y eso no es lo que queremos.
¿Vale?
Entonces.
Yo creo que no está tan bien.
Que esté aquí.
Por lo tanto.
Lo que vamos a hacer.
Con todo este código.
Es eliminarlo.
¿Vale?
Lo eliminamos.
No vamos a actualizar nosotros.
La caché.
A partir de eso.
Pero sí que podemos hacer.
Es actualizar la caché.
En un solo punto.
Y ese punto puede ser este.
Nos podemos suscribir aquí.
Así que.
Ya hemos visto que es con esto.
Con la ad person.
Voy a añadir esto aquí.
Este data in store.
Tenemos que leerlo de la store.
Pero la store.
¿Dónde la tenemos?
La store en realidad.
Es el cliente.
Así que el cliente.
Que lo tenemos aquí.
En la línea 18.
Podríamos hacer aquí.
Client.
Leeríamos la query de all persons.
Y el client.
Podríamos hacer un write query.
Hasta aquí.
Hay una cosa que.
Que es un poco diferente.
A como lo explican.
En el full stack.
En el bootcamp este.
¿Vale?
Y.
¿Por qué yo considero.
Que esto está mejor.
Que lo que hacen.
En la documentación.
Ellos en la documentación.
Lo que hacen.
Es dejar los dos.
Dejan.
Este aquí.
Y.
Dejan este aquí.
Y entonces.
Hacen un if.
Para ver.
Si realmente.
Esa persona.
Ya está añadida.
O no está añadida.
Pero se ejecuta el código.
Dos veces.
Yo considero.
Que eso es una muy mala práctica.
¿Vale?
Lo primero.
Porque están manteniendo algo.
Tú.
Muy manualmente.
De tener que ver.
Si la idea.
No sé qué.
No sé cuánto.
Lo segundo.
Que es.
O sea.
Es código duplicado.
Porque realmente.
Aquí tienes una suscripción ya.
Y es mejor que tengas una fuente de la verdad.
En la que solo te suscribas en un punto.
¿Vale?
Y lo tengas más controlado.
Que no.
A lo largo de tu aplicación.
En un montón de sitios.
Hagas este tipo de comprobaciones.
De.
Hackear la cache.
Para hacer esto.
Entonces.
Yo te recomendaría.
Hacerlo en un solo punto.
En un solo sitio.
Que tenga la suscripción.
Y ya está.
Y evitar.
Pues ir teniendo código.
Por ahí repetido.
Luego.
El ADPerson este.
Es justamente el que queremos añadir.
Ves que aquí antes lo sacamos.
De response.data.adperson.
Esto ahora lo tenemos que sacar.
De aquí.
El ADPerson.
Que es el que.
Nos está devolviendo la suscripción.
Creo que esto.
Está bien.
ADPerson.
Yo creo que sí.
ADPerson.
ADPerson.
Creo que no se me escapa nada.
Vamos a verlo.
¿Vale?
Vamos a ver si esto funciona.
Refresco.
Vamos a añadir.
Una persona más.
A ver qué me dice por aquí.
Venga.
Oscar HN27.
Acaba de llegar.
Oscar HN27.
Que tiene un teléfono así.
Y que dice JSX TypeScript.
TypeScript luego.
Y lo añadimos.
¿Vale?
Vale.
Ha petado.
Igual he hecho algo mal.
No pasa nada.
Vamos a ver qué he hecho.
Can't reprove the time name of undefined.
Ostras.
Qué súper raro este error.
Vamos a ver qué he hecho por aquí.
ADPerson.
Igual he hecho algo mal.
Client.
El error es que es súper raro además.
Can't reprove the time of undefined.
A ver.
A ver.
Que se ha grabado.
Se ha grabado seguro.
¿Veis?
Se ha grabado seguro.
Lo que no sé es porque no ha funcionado en la suscripción.
Vamos a ver si en la de person.
Yo creo que está la de person.
A ver si la he liado aquí.
Unsubscripción data.
Tenemos aquí subscription data.
En person form.
Esto lo he grabado bien.
Subscription lo he grabado bien.
Y then name form.
A ver si he liado alguna cosa.
Query all persons.
Y la query del cliente.
Yo creo que es esto.
Está bien.
Bueno.
No sé.
Vamos a ver.
Otra vez.
A ver si.
No sé.
Igual se me ha apagado algo.
Ahí.
Vamos a ver.
Con el Oscar.
Vamos a ver.
Bla, bla, bla.
Bla, bla.
Bla, bla.
Bla, bla.
A person.
Vale.
¿Veis que me da aquí undefined?
¿Vale?
Esto es porque no es exactamente.
Como yo he hecho esto.
Desubscripción data.data.adperson.
No me está devolviendo esto así.
Igual es que me he equivocado.
Es person added.
He puesto added person y es person added.
Ya está.
Ese es el tema.
Lo cual me parece muy bien.
Que nos pete ahí en toda la boca.
Vale.
Ahora vamos a añadir otro.
Vale.
Add person.
Ahora sí.
¿Vale?
¿Veis?
Ahora sí.
No.
El problema es eso.
Que aunque mira que he visto la suscripción.
Pero era person added en lugar de added person.
Entonces con esto ahora sí estamos añadiendo bien la persona.
La suscripción ha funcionado correctamente.
Y lo estamos haciendo desde un solo punto.
Lo mejor de esto además es que esto.
Esta parte de aquí lo podríais extraer por ejemplo en un custom hook.
Que esto ya lo vimos ¿no?
Use subscriptions.
Por ejemplo.
Por si queréis tener todas las suscripciones en un solo sitio.
Entonces podéis hacer esto.
Use subscriptions.
Tenéis todas las suscripciones en un solo sitio.
De hecho aquí esto ya podríais devolver true.
Por decir algo.
Si queréis.
O podréis devolver el cliente.
En el caso de que queráis devolver el cliente por qué motivo.
Y todo esto que tenemos aquí.
Que lo habíamos dejado así.
Pues podríamos hacer use subscriptions.
Y hacer esto así.
Por ejemplo.
Ya os digo.
Siempre os dije ¿no?
Que a mí me gusta mucho trabajar con un custom hooks.
Para hacer que este tipo de lógica sea agnóstica a tu componente.
Bueno.
Pues esto es súper fácil que los traigáis.
De esta forma.
¿Vale?
Lo voy a tirar para atrás.
Porque como no tengo el inter.
No sé si me he olvidado alguna cosa.
Pero que funcionar debería funcionar sin ningún problema.
A ver si queréis lo intentamos.
No vamos a quedar con las ganas de ver si funciona.
Venga.
Vamos a pillar otro nombre.
Si pone.
Venga.
Pues vamos a poner a Renato Mendozac.
Que tiene teléfono.
Y tenemos person added.
No added person.
Añadimos a personita.
¿Vale?
Y veis.
Aquí está.
Perfecto.
Funcionando.
Con nuestra suscripción y todo.
Y lo tenemos ahora aquí a un custom hook.
Que esto lo podríamos añadir en un solo sitio.
Y ya estaría.
Y lo ponemos aquí.
Use subscription.
Lo llamamos en un solo sitio.
Y nos olvidaríamos un poco de todo el tema de las suscripciones.
A mí me parece súper ventajoso.
Que ya no tienes que poner el tema de la caché en un componente.
Y ya está.
Esto sería como trabajar una suscripción.
Ahora.
Claro.
Ahora viene la pregunta del millón.
Obviamente.
¿Qué es del palo?
¿Cuándo utilizar las suscripciones?
¿No?
O sea.
¿Cuándo debería utilizar suscripciones en GraphQL?
A ver.
Las suscripciones son carillas.
¿Ok?
Es normal.
No añadáis.
No hagáis todo con suscripciones.
En este caso.
Por ejemplo.
Esto depende mucho del negocio.
¿No?
Por ejemplo.
Añadir una persona.
A ver.
Si es una aplicación que se añade en muchas personas.
Y necesitas en tiempo real ver las personas.
Pues seguramente sí que puede ser salirte a cuenta el tema del WebSocket.
Pero los WebSockets son caretes.
Son caretes.
En tema de escalabilidad.
En tema de eficiencia.
¿Por qué?
Porque claro.
Son en tiempo real.
¿No?
Entonces.
Un WebSocket es más eficiente que un HTTP en tema de si tienes que hacer polling.
O que es preguntar constantemente esos datos.
Pero.
Si el WebSocket al final lo vas a revisar cada 10 minutos.
15 minutos.
O nunca.
Pues seguramente es mejor un HTTP.
Que haces una vez la petición.
Cierras y ya está.
¿Vale?
O sea que.
¿Para qué es interesante?
Pues para pequeños cambios.
Que sean incrementales para objetos.
Por ejemplo.
Pues ver cuando se le ha dado like a un tweet.
Eso es súper interesante.
¿No?
Porque puedes ver el contador como va creciendo.
Y a lo mejor te interesa.
Pues detectar cuál es el tweet que tiene el usuario ahí abierto en el viewport.
Y suscribirte rápidamente a eso.
Para ver cómo le va creciendo el contador de likes.
Pues eso puede ser interesante.
Algo que sea pequeño.
¿No?
De objetos que son muy grandes.
Como el post de Twitter.
Pero es pequeño lo que quieres observar.
Porque solo son el tema de likes.
Ese puede ser uno.
Luego.
Si necesitas tiempo real.
¿Vale?
Si necesitas cosas que tengan latencia muy corta.
Muy pequeñita.
Y sean a tiempo real.
Un chat.
Mensajes de un chat.
O es obvio.
¿Vale?
Tiene todo el sentido del mundo.
¿Cuándo no tiene sentido que utilicéis suscripciones?
Crear un usuario.
Pues imaginad que creáis un usuario.
Bueno.
No sé hasta qué punto.
Tienes que observar con una suscripción.
Cuando salga.
A lo mejor puedes hacer una revisión.
Puedes hacer el check cada cinco minutos.
O puedes hacer el refresh queries.
Que es el que vimos la última vez.
Es decir.
Bueno.
Pues cada.
Cuando ocurra esta mutación.
Pues hago un refresh.
Pues es una cosa que pasa una vez.
Pues seguramente no valga la pena hacer una suscripción.
¿Ok?
Así que con esto hemos visto los fragments.
Y hemos visto las suscripciones.
Suscripciones que son súper potentes.
Pero intentad no hacer todo.
Que sean suscripciones.
Sino que cuando tenga sentido.
Venga.
Que os leo.
Venga.
Que os leo.
¿Me puedes explicar para qué se usa GraphQL y las ventajas de usarlo?
Madre mía.
Moisés.
A ver.
Eso lo vimos hace dos clases.
En la clase anterior lo volvemos a comentar.
¿Vale?
Pero al final GraphQL tiene un millón de ventajas.
Pero se resumen dos.
Overfetching y...
¿Cómo sería lo contrario?
Básicamente es cuando tienes que...
Para pintar una aplicación necesitas hacer llamadas a 5 o 10 APIs diferentes.
Pues con GraphQL podrías hacer la llamada solo a GraphQL y traerte solo la información que necesitas.
Eso sería básicamente lo bueno de GraphQL.
Y además el cliente es totalmente agnóstico a donde saca esa información.
GraphQL tú lo puedes conectar a cualquier base de datos, a cualquier API, a PREST, a otro GraphQL.
Lo puedes conectar a un montón de sitios.
Es genial.
Así que esa es la ventaja que tiene.
Que es súper óptimo en el sentido de la información que te traes.
Las conexiones solo harías una.
Y en una sola petición podrías traerte toda la información que necesitas.
Y te devolvería exactamente lo que le has pedido.
Eso es la gran ventaja que tiene.
Además de que es súper predecible.
Porque la información que le pides es la que te devuelve.
No es como una API REST que tú le puedes pedir información.
Pero tú no tienes con total seguridad...
Tú no sabes cómo va a ser el objeto que te devuelve.
Porque puede cambiar al otro lado.
En GraphQL esto no puede ocurrir.
Porque tenemos unas definiciones.
Y tú en el cliente si le dices yo quiero un objeto que sea tal, tal y tal...
Te tiene que devolver ese objeto o peta directamente.
Eso sería un poco el tema.
¿En qué andamos?
¿En WebSockets?
Bueno, suscripciones de...
Más bien en suscripciones de GraphQL.
¿Vale?
Que te crea WebSockets directamente.
Una pregunta.
Si tienes varias suscripciones, va al método indicado.
No hay un undefined.
Si tienes varias suscripciones, va al método indicado.
O sea, al final tú puedes suscribirte más de una vez.
Obviamente, ¿eh?
O sea, mira, tú aquí, en este Use Subscriptions, tú, esta Use Subscription Personal, esto te puede suscribir tantas veces como quiera.
Fíjate.
O sea, podríamos poner aquí una suscripción que cuando recibe data, pues aquí hace una cosa.
Y aquí podrías hacer otra, otra cosa.
No sé si esto...
A ver, no lo recomiendo.
Intentaría evitar esto porque si no, podéis volver un poco locos.
Y con una sola suscripción debería ser suficiente.
Y aquí, pues, hacerlo todo.
Pero esto debería funcionar sin ningún problema.
Y va al método indicado, claro.
O sea, tú le dices Use Subscription.
¿Cuál es la suscripción?
Person Added.
Person Added es la que tenemos aquí.
Entonces, esta suscripción la tienes ya en el servidor indicada.
Cuando ocurre, cuando esa suscripción recibe datos, pues al final lo que hace es ejecutar este método y ya está.
Te puedes suscribir más de una vez.
No lo recomiendo.
Porque si ya os habéis suscribido una vez aquí, ya aquí podéis hacer todo lo que queráis.
Y podéis tener un montón de métodos y ya estaría.
Bueno, siempre he pensado que tampoco hay muchísima diferencia entre JavaScript y JavaScript.
¿Qué opinas?
Pues ahora lo vamos a ver.
¿Todo el curso lo subes a tu canal?
Sí.
Sí lo subo a mi canal.
Y no te puedes perder mi canal porque seguramente es el mejor canal de YouTube y el más modesto.
Y el más humilde también.
Sí, este es mi canal.
Es midu.tuve o midudev, como veas.
Voy a pasar ahí el enlace y empezamos ya con TypeScript, ¿vale?
Ahí en listas de reproducción está la lista de reproducción del bootcamp y están todas las clases que hemos ido haciendo,
aunque están incluso editadas para que las veáis más fácilmente.
Claro, decía, si tienes otro, ¿cómo modificar?
Pero claro, me quedó claro porque es porque el string va de un lado a otro.
¿Vale?
¿No utilizas la generación de código?
¿El package que genera interfaces en base a los puntos GraphQL?
No lo he utilizado, pero sí, hay un montón que te puede permitir generar las interfaces de TypeScript,
pero no vamos a ver TypeScript con GraphQL, ¿vale?
Pero es verdad, hay un montón de...
Si tenéis los .graphql te puede generar los tipos y es súper útil.
Venga, pues vamos a TypeScript, ¿vale?
Vamos a pasar a una nueva parte con TypeScript.
Y os vamos a comentar un poco qué es TypeScript y por qué es interesante TypeScript.