lo que pedimos. Entonces, um, eso puede que no sea muy intrigante. Uh, estarás pensando, vale, ya puedo hacer todo esto con REST. Puede que no sea tan elegante o llamativo como tus, ya sabes, pequeñas solicitudes en forma de JSON, pero ya puedo hacer eso. Um, uno de los lugares donde
GraphQL realmente brilla, uh, es en las APIs en tiempo real. Entonces, um, lo cubriremos un poco más adelante, pero, um, las suscripciones son el tercer tipo de operación y te permiten suscribirte a los datos, como su nombre lo indica. Por ejemplo, podrías ejecutar una suscripción y decir, um, suscripción, uh, uh, mensajes en los últimos 10 minutos. Y luego, tu, uh, cuerpo de suscripción sería algo como mensajes donde, um, updated_at es menor o igual, ya sabes, date.now menos 10 minutos. Correcto. Y cada vez que la base de datos, um, tenga un nuevo registro que cumpla con ese requisito, recibirás una notificación en tiempo real con los nuevos datos. Y eso te permite construir interfaces de usuario reactivas, uh, y en tiempo real de manera muy fácil. Uh, y esta funcionalidad, para aquellos que han trabajado en la construcción de aplicaciones basadas en websockets utilizando cosas como Socket IO, Socket IO, uh, suele ser mucho trabajo adicional además de tu API CRUD regular. Entonces, la forma en que funcionaban las APIs en tiempo real antes era, uh, tenías una opción, que era la encuesta. Entonces, simplemente, ya sabes, cada X segundos, hacías esta solicitud repetida, uh, que no es la forma más eficiente de hacerlo. La otra opción que tenías era, uh, uh, websockets y, uh, eso permite que el servidor envíe los datos al cliente. Um, no sé si necesariamente es una pesadilla, pero, puede volverse muy complicado, especialmente cuando tienes muchos clientes suscritos. Um, y necesitas gestionar las conexiones correctamente. Uh, especialmente cosas como la presión trasera, um, y manejar el estado de conexión y desconexión. Um, después de eso, um, la forma en que funciona en
GraphQL es que básicamente apuntas tu cliente de
GraphQL o tu cliente de websockets a tu punto de conexión de
GraphQL. Nuevamente, el mismo punto de conexión único y escribes tu suscripción. Y así, como aquí, estamos diciendo, uh, me gustaría suscribirme al pedido con este ID. Y quiero saber si ha sido pagado y si ha sido enviado. Cuando se actualice ese pedido, uh, nuestra interfaz de usuario será notificada de inmediato y tendremos los valores actuales, uh, y más recientes de pagado y enviado. Y podemos hacer con eso lo que queramos. Otro gran beneficio de las APIs de
GraphQL y, uh, tal vez uno de los más grandes, es lo fácil que es, es documentar y compartir la API. Entonces, um, no sé cuántos de ustedes trabajan en startups, uh, o han intentado arrancar, uh, cosas de software, pero, uh, el ciclo de vida típico de la documentación de desarrollo es que el desarrollador de la API, construye la API, el desarrollador de la API escribe la documentación, que termina en hojas de cálculo de Google o en postman o swagger. Um, lees la documentación y finalmente comienzas a integrar la API, pero la documentación está incompleta, desactualizada, uh, o simplemente incorrecta. Um, o el escenario más realista es que un desarrollador de API construye una API y no hay documentación. Um, así que con
GraphQL, la forma en que funciona es que construyes tu API de
GraphQL, y eso es todo. Um, tú o quien sea responsable de la integración, ya sea en el lado del servidor o en el lado del cliente. Porque
GraphQL funciona en ambos. Y veremos eso hoy, simplemente comienzas a integrarlo y siempre, siempre, siempre está sincronizado. Um, y la razón de esto es debido al sistema de tuberías. Um, no entraremos demasiado en esto, pero
GraphQL tiene su propio pequeño lenguaje de definición de esquemas, lo que llaman SDL (Schema Definition Language). y es un lenguaje para definir tipos, uh, para tu servicio gráfico y también, um, operaciones que puedes realizar en un servicio. Um, si un tipo o una operación no existe en las definiciones de esquema, no puedes escribir un resolvedor para ello. Entonces no hay escenario en el que algo esté disponible en la API y no esté documentado. Uh, los tipos se parecen mucho a
TypeScript, uh, o, uh, SWIFT o Kotlin o cualquier otro lenguaje de tipos con sufijo. Correcto. La parte realmente interesante, uh, es esta capacidad de introspección que tiene
GraphQL, que básicamente puedes decirle a
GraphQL, uh, puedes enviarle una consulta especial y básicamente decir, Oye, cuéntame sobre todos los tipos en tu API. Cuéntame sobre todas las operaciones en tu API. Um, y es auto-documentado y luego puedes generar, ya sabes, todo tipo de sitios de documentación agradables y visualizaciones ERD. Um, nadie tiene excusa para ser demasiado perezoso para escribir la documentación porque simplemente los tipos están ahí para ti. Um, um, así que esta es la parte donde comenzaremos a construir cosas. Um, hay un par de diapositivas después de esta. Son solo cosas accesorias. Um, debería haber puesto esta al final, así que fuera de esto, hay algunos beneficios realmente interesantes de usar
GraphQL, como obtener verificación de tipos e IntelliSense y operaciones dentro de tu IDE. Um, y estas se pueden ejecutar contra un esquema en vivo, por lo que es como tener una documentación de esquema tipado, uh, a tu disposición. Uh, y la otra forma de hacer esto es usar herramientas como el generador de código de
GraphQL, um, que puede generar código tipado para muchos
frameworks diferentes, como
React,
Vue,
Apollo, um, y otros más. También puede hacerlo en el lado del servidor. Uh, por lo que puede generar SDK que funcionan en node, um, e incluso tiene complementos para cosas como C# y Scala.
Comments