Name: Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Uploaded: 2024-04-11T14:00:00.000Z
Duration: 2 h 32 min 28 s
Description: Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.

Como introducción, mi nombre es Emmanuel Skulet, y junto con mi colega Miguel Tastana, vamos a guiarlos a través del masterclass hoy. Vamos a construir juntos una aplicación muy buena que utiliza la API de <a href="/tags/graphql">GraphQL</a>. Y veremos cómo se puede hacer eso en <a href="/tags/aws">AWS</a>. Y hemos preparado todo para ustedes, así que no es necesario que tengan ningún tipo de software instalado en su computadora. Ejecutaremos todo en un entorno virtual. Ambos somos parte del equipo de servicios profesionales de <a href="/tags/aws">AWS</a>, en caso de que no estén familiarizados con eso. Esa es la división de consultoría de <a href="/tags/aws">AWS</a>. Trabajamos directamente con, de hecho, ambos, los clientes más grandes que tenemos en <a href="/tags/aws">AWS</a>. Y desde hace varios años, hemos estado construyendo aplicaciones con clientes. Y también podemos compartir con ustedes algunas de las tendencias que vemos y por qué es importante que aprendamos la última tecnología y veamos cómo esto puede ser adoptado por empresas y startups también. Entonces, en la agenda de hoy, les mostraremos un poco de las fortalezas que vemos en términos de aplicaciones modernas en 2024. Hablaremos sobre qué es <a href="/tags/graphql">GraphQL</a>, cómo funciona, y luego la implementación de <a href="/tags/graphql">GraphQL</a> en <a href="/tags/aws">AWS</a>, que es un servicio llamado <a href="/tags/aws">AWS</a> AppSync. Nuevamente, no se requiere conocimiento de los servicios. Es solo una implementación de la especificación y la utilizaremos a lo largo del masterclass. Y después de eso, pasaremos al masterclass en sí, donde construiremos una aplicación, construiremos una API, aseguraremos esa API y veremos cómo funciona todo el flujo de principio a fin. Y al final, les daremos algunos puntos clave. Esperemos que esta sesión sea muy útil y puedan aplicar lo aprendido

aprendizajes de esto justo después de este. Así que estoy muy curioso por saber cómo será su retroalimentación. Entonces dicho esto, quiero hablar un poco sobre qué es una aplicación moderna en 2024. No sé ustedes, pero en mis primeros días, comencé a construir aplicaciones en las instalaciones. Y en aquellos días, era bastante complicado porque tenías que solicitar VMs con anticipación, balanceadores de carga con anticipación, entradas DNS, y así sucesivamente. Así que eso llevaba mucho tiempo, semanas y meses si recuerdo bien, antes de poder comenzar. Y si comienzas a construir microservicios, vas a necesitar mucha infraestructura para eso. Así que en estos días, cuando construyes una aplicación, esperas que la infraestructura esté disponible de inmediato. Y deberías poder aprovisionarla en cuestión de segundos, deberías poder esperar desplegarla globalmente para llegar a los clientes en todas partes sin mucha sobrecarga. Obviamente, si miras algunas de esas aplicaciones super grandes que probablemente todos estamos usando hoy en día, como no sé, Instagram o Uber o TikTok y demás, esas aplicaciones responden súper rápido, ¿verdad? Así que se ha convertido en una expectativa que construyamos aplicaciones de esa manera. Y obviamente, nadie está haciendo versiones o bueno, no nadie, pero muchas empresas y muchos clientes quieren lanzar tan frecuentemente como sea posible a sus propios clientes, para que tengan características listas lo antes posible. Así que todo esto, en conjunto, son cosas que esperamos tener en las aplicaciones en 2024. Y yendo quizás al siguiente nivel de detalle aquí, puedo cambiar la diapositiva, esperamos tener la latencia más baja posible mientras atendemos a usuarios en todo el mundo, deberíamos poder escalar para manejar grandes cargas de trabajo, ¿verdad? Si piensas en una plataforma de comercio electrónico como amazon.com, ¿verdad? Esperamos que durante eventos como el Black Friday, el sitio web no se caiga, ¿verdad? Así que gestionar una tarea así requiere bastante ingeniería, pero eso se está convirtiendo en una expectativa de que no necesitamos necesariamente hacer algo específico para ese evento específico, la aplicación debería ser capaz de hacerlo por sí misma. Obviamente, también deberíamos poder hacerlo con un costo razonable, ¿verdad? No queremos que nuestros costos se disparen fuera de nuestro control. Y ese costo también debería ser predecible, ¿verdad? No queremos tener, ya sabes, millones de dólares de costos de infraestructura aplicables cuando construimos dichas aplicaciones. Y, por supuesto, como puedes ver, en estos días hay una gran tendencia con GNI, pero esto también ha sido el caso en el pasado, como en el pasado también teníamos mucha ingeniería de datos y aplicaciones de análisis de datos, muchos solicitantes o tráfico de participación de usuarios. Así que hay muchas tendencias que surgen cada ciertos años, este año y el año pasado han sido mucho sobre GNI. Entonces, los clientes también quieren experimentar con esas últimas tecnologías en esta aplicación, así que debemos hacerlo lo más fluido posible. Y cuando se trata de interfaces de usuario, muchas de las tendencias que vemos, obviamente, es que tenemos un par de ganadores aquí. Y ha habido, creo, un poco de debate sobre lo que está sucediendo en los próximos años. Así que en la cima en este momento está <a href="/tags/react-components">React</a>. Todavía hay bastante tracción alrededor de <a href="/tags/angular">Angular</a>, pero también hay algunos nuevos <a href="/tags/frameworks">frameworks</a> emergentes que también están recibiendo atención. Veremos cuáles se vuelven dominantes en los próximos años. Pero la idea detrás de esto es que no necesariamente debemos quedarnos con una tecnología específica que tal vez funcione hoy. Y deberíamos poder iterar y evolucionar esas tecnologías según sea necesario para un caso de uso específico que podamos tener. Si te preguntas, ya sabes, ¿no tenemos suficientes aplicaciones ya? Creo que hemos construido muchas, tanto en el espacio de consumo como en el espacio empresarial, muchas de ellas. ¿Y por qué todos siguen interesados en construir dicha aplicación? Como mencioné, la gente habla mucho en estos días sobre las aplicaciones de GNI, pero hay tantos otros casos de uso que tal vez no sean tan, digamos, populares o no tan visibles en el mercado, pero definitivamente están sucediendo. Entonces, una gran razón por la que los clientes construyen aplicaciones es porque quieren acelerar el espacio de innovación y obtener muchas más ideas sobre los datos que ya tienen. Así que si piensas en compañías farmacéuticas o compañías de energía, han estado recopilando datos durante varias décadas, mucho tiempo, ¿verdad? Y todavía están rezagados en el uso de esos datos para desarrollar nuevos productos. Tal vez hayas notado eso durante el tiempo de COVID, ¿verdad? Creo que fue un gran momento para la industria farmacéutica, donde comenzaron a utilizar datos para hacer experimentos y simulaciones. Y esa es una de las razones por las que pudieron innovar tan rápido en esas vacunas. Así que ese es un gran impulsor, ¿verdad? Los clientes tienen muchos datos, terabytes, a veces petabytes, y aún quieren construir aplicaciones en torno a ellos para obtener nuevos conocimientos comerciales e identificar nuevas oportunidades para construir nuevos productos o mejorar los productos existentes. Y como mencioné, ¿verdad? Este año, tenemos la tendencia de GNI. Así que todavía quieren aprovechar, de hecho, tengo muchas conversaciones con mis clientes sobre este tema de cómo pueden implementar GNI en aplicaciones existentes para simplificar aún más los flujos de trabajo y automatizar algunos de ellos, ¿verdad? Así pueden enfocar sus recursos y personas en otras partes del negocio. Entonces, esos son todos los grandes impulsores por los cuales los clientes construyen aplicaciones, y también verán las tendencias sobre qué tipo de aplicaciones están construyendo. Si observamos algunos de los casos de uso, los clasificamos en un par de categorías aquí. Entonces, una gran clase de aplicaciones son las del espacio de <a href="/tags/iot">IoT</a>. Así que si piensas en industrias y medidores inteligentes y gestión de dispositivos, también estamos hablando de dispositivos de consumo, ves en estos días que cada vez más electrodomésticos se están volviendo inteligentes, para mejor o peor, algunos de ellos, en mi opinión, no necesariamente una gran adición. Pero definitivamente ves refrigeradores inteligentes, hay lavadoras inteligentes, cocinas y demás. Así que hay todo un sistema detrás de eso, ¿verdad? Puede ser complejo, obviamente hay mucha interacción entre esas aplicaciones y demás. Pero hay muchas, muchas de ellas y sigue creciendo, ¿verdad? En algún momento se vuelve como una actividad, hay una aplicación para cada fabricante para cada dispositivo. Así que también los consumidores, los clientes, nuestros clientes están buscando cómo simplificar eso y construir experiencias más unificadas. Y luego también hay muchas aplicaciones en el mundo industrial, piensa en fábricas y en mucha optimización de procesos, esto entra en el mundo industrial donde las personas o los clientes buscan hacer, digamos, procesos más eficientes para obtener más información cuando las cosas se atascan y por qué, e incluso hacer mantenimiento predictivo, ¿verdad? Así que pueden resolver problemas antes de que aparezcan y así no tener ningún tipo de tiempo de inactividad en las fábricas. Otro gran tipo de aplicaciones son las del espacio de análisis, como dije, esto es como un reino que nunca deja de crecer y expandirse, ahora con GNI, pero como mencioné, los clientes tienen muchos datos, ya sea datos de ventas o tratar de hacer cualquier tipo de inteligencia de negocios sobre cómo van sus campañas de marketing, así que hay muchas oportunidades en este espacio, y es un gran impulsor para construir tales aplicaciones. Luego tienes esta creatividad y potencia de IA, conectada, así que creo que hace dos o tres años, hubo una locura con los motores de recomendación, debido a Netflix, digamos, que comenzó esta tendencia. Así que todos estaban buscando motores de recomendación, y tenía colegas que trabajaban en el espacio de medios y entretenimiento, y lo estaban haciendo para periódicos, estaban mirando las tendencias de Google, e incluso estaban automatizando cómo los periódicos escribían artículos. Así que eso todavía, creo, está sucediendo, hay muchas traducciones, por ejemplo, traducciones automáticas, así que si quieres construir una aplicación que sea accesible para todo tipo de clientes en todo el mundo, a menudo con muchos idiomas diferentes, puedes hacer todo eso sin necesariamente tener personas que estén en el medio y tener esos retrasos cuando estás implementando aplicaciones. Así que hay mucha automatización en marcha, y ese es otro gran impulsor. Y luego estamos hablando de aplicaciones tipo plataformas, esas son tal vez las más complejas en términos de complejidad, los mayores tipos de aplicaciones, y aquí podemos pensar en procesamiento de documentos, sistemas de conducción autónoma, esas son plataformas enormes que requieren mucho datos y requieren mucha infraestructura para poder operar, mercados, sistemas de venta de boletos y reservas, y demás. Así que esas son las categorías de casos de uso de aplicaciones que vemos como los principales impulsores y los principales impulsores para la adopción. Ahora, si nos fijamos en algunas de las tendencias de aplicaciones que hemos visto en los últimos años, definitivamente vemos muchas aplicaciones de desarrollo <a href="/tags/cross-platform">cross-platform</a>, principalmente con iOS y Android, y si eres una startup o tal vez tienes recursos limitados, esto es un gran impulsor. Así que tenemos un par de <a href="/tags/frameworks">frameworks</a> aquí con Flutter y <a href="/tags/react-components">React</a> Native que se mantienen en la cima. Y luego, tal vez de interés para esta sesión de hoy también es que muchas empresas están considerando adoptar <a href="/tags/graphql">GraphQL</a>, y la razón de eso es está conectada con estas aplicaciones de gran cantidad de datos, porque <a href="/tags/graphql">GraphQL</a> es exactamente el ámbito en el que realmente brilla. Incluso con uno de mis clientes más grandes, el año pasado tuvimos una gran adopción de <a href="/tags/graphql">GraphQL</a> y recuerdo que cuando les hablé por primera vez sobre la tecnología, estaban un poco escépticos porque realmente no tenían experiencia interna. Pero ahora, un año después, están súper contentos con eso y se ha convertido en la opción predeterminada para las aplicaciones de gran cantidad de datos y análisis. Y como puse aquí como último punto, y una de las principales razones por las que estamos haciendo esta sesión hoy es porque todavía hay una gran escasez de desarrolladores. Las empresas todavía están buscando a esos desarrolladores. Recuerdo que otro cliente mío estaba buscando a cientos de personas con habilidades específicas y tenían dificultades para encontrarlas en el mercado porque muchos desarrolladores, una vez que aprenden una tecnología, se quedan con ella durante muchos años. Y el panorama tecnológico está evolucionando muy, muy rápido. Ves que desde hace cinco años, los <a href="/tags/frameworks">frameworks</a> y tal vez los lenguajes desaparecen. Para mí, por ejemplo, ni siquiera veo un lugar, digamos, importante, para Java en el futuro o lenguajes como ese. Así que la tecnología está evolucionando, puedes estar en desacuerdo con eso, pero básicamente es en lo que vemos mucho, ¿verdad? Y lo que está sucediendo en el mundo, obviamente hay tendencias y muchas empresas también quieren ser relevantes en el mercado laboral, ¿verdad? Así que también tratan de adoptar estas tecnologías, además de ser un gran impulsor para que sean relevantes. Ahora, si nos fijamos en los desafíos al construir APIs, tenemos diferentes tipos de aplicaciones, como discutimos, en diferentes industrias, con diferentes casos de uso, y tenemos un par de tecnologías de API que alimentan todas estas aplicaciones, ¿verdad? Así que para aquellos de nosotros que tal vez somos un poco mayores en la industria, todos tal vez hemos escuchado o hemos visto APIs SOAP, no las recomendamos, y por eso nos hemos alejado de ese mundo, aunque, nuevamente, todavía existen. Así que no las descartes por completo, pero como dije, la tecnología está evolucionando. Y luego tenemos, creo, dos fuerzas dominantes en el mundo de las APIs. Uno es todavía el predeterminado, que son las APIs REST, y luego tenemos al nuevo niño en el bloque, aunque no es tan nuevo, pero aún así, digamos, una tecnología emergente, que es <a href="/tags/graphql">GraphQL</a>. Y luego tenemos varias variantes de RPC. Y esos casos son un tipo de casos de uso específicos para APIs súper eficientes y súper rápidas que tienen un caso de uso muy específico. Ahora, lo

Así que con eso, me gustaría pasarle la palabra a mi colega, Miguel, quien hablará sobre esas cosas. Gracias, Manuel. Excelente introducción. Justo antes de detenerme allí, gracias a todos por unirse a nuestra sesión. Apreciamos mucho que inviertan su tiempo para escucharnos. Esperemos no decepcionarlos. Siguiendo la lógica que Manuel mencionó hasta ahora con <a href="/tags/graphql">GraphQL</a>, ¿por qué de repente comenzó a aparecer y a tener un resurgimiento? Es cierto que REST sigue siendo el predeterminado porque es accesible. Es algo que está estandarizado en Internet. Es el contrato de interfaz que se define para muchas aplicaciones. Y no veo un futuro en el que REST desaparezca. No, ese no es el caso. Pero hay más opciones. Y eso es lo maravilloso de la tecnología, que puedes tener un gran conjunto de tecnologías que se adaptan, que pueden ser elegidas específicamente para tu caso de uso. Pero antes, lo que queremos hacer aquí hoy es realizar un ejercicio en el que REST y <a href="/tags/graphql">GraphQL</a> brillan y por qué <a href="/tags/graphql">GraphQL</a> ha ganado tanto poder en ciertos tipos de aplicaciones y casos de uso. Y el primero, y vamos a dividirlo esencialmente en dos categorías. Hay un problema técnico que hizo que la gente se inclinara hacia <a href="/tags/graphql">GraphQL</a>, y Facebook desarrolló <a href="/tags/graphql">GraphQL</a>. Y también hay un problema organizativo. Pero centrándonos primero en la tecnología, ve al siguiente diapositiva, Emanuel, es el caso de uso del underfetching. ¿Y qué significa el underfetching? Estoy seguro de que habrá personas en el chat que ya han escuchado este tema, pero solo para asegurarnos de que todos estemos en la misma página. Con el underfetching, estamos describiendo una situación que es bastante común en APIs más complejas, APIs REST, donde una única solicitud de red no puede satisfacer todos los datos que necesitas. Un ejemplo de esto es cuando estás desarrollando una página web o una página para el perfil de usuario en tu aplicación móvil. Es común que necesites obtener esta información de diferentes almacenes de datos, diferentes servicios, tal vez cosas propiedad de diferentes equipos. Así que terminas en esta situación en la que necesitas realizar múltiples solicitudes y encontrar datos dispersos en múltiples sistemas y equipos, solo para proporcionar una vista consistente. Y lo que <a href="/tags/graphql">GraphQL</a> realmente promueve es

una simplificación de esta complejidad al cliente. Así que si pasamos a la siguiente diapositiva, Emanuel, y creo que podemos alternar entre las dos. Pero la idea es que en lugar de tener toda esta complejidad en el lado del cliente, y tener que hacer estas uniones complejas en el lado del cliente, y solicitar dependencias, esperar a que una tenga el ID para hacer la otra. En lugar de tener toda esta complejidad, básicamente puedes transferir o abstraer esa complejidad a <a href="/tags/graphql">GraphQL</a>. Y vamos a explicar cómo se hace. Pero este es un modelo conceptual más allá de <a href="/tags/graphql">GraphQL</a> que permite que tus consultas estén más cerca de los datos y menos ligadas a tu contrato de API y cómo está limitado por la forma en que fue diseñado. Esto te da una gran flexibilidad en cómo consumes. Y es extremadamente poderoso en situaciones en las que estás gestionando un modelo de datos complejo, o no tienes patrones de acceso estables o muy bien definidos, lo cual es muy común. Porque sí, dices ahora que comienzas una aplicación hoy, y haces tu aplicación. Sí, es perfecta. Tengo todos los puntos finales que satisfacen mis vistas. Es perfecto. Pero como ves, a medida que pasa el tiempo, oh, ahora necesitas agregar esta función. Y ahora necesitas compartir cosas. Y esto rápidamente se convierte en una API REST inmantenible, donde tienes o bien puntos finales súper genéricos, que luego requieren lógica compleja en tu API, o tienes esta lógica compleja en el lado del cliente. Así que esencialmente estás haciendo este ejercicio de cambiar entre un lado y otro. Y aquí es donde <a href="/tags/graphql">GraphQL</a> realmente facilita las cosas. El ejemplo que tenemos aquí es, sería genial cuando estás haciendo Facebook o Instagram o LinkedIn, si pudieras obtener toda la información que se requiere para mostrar en esa vista en una sola solicitud. Y hay beneficios en esto. Además de la complejidad, el hecho de que solo hagas una solicitud a través de Internet significa que con suerte la latencia y los tiempos de respuesta también serán mejores. Por lo tanto, la capacidad de respuesta y la sensación para ti, para tu experiencia de usuario también tendrán una forma de ser mejor y para el usuario final. Si pasamos a la siguiente diapositiva, Emmanuel. En cuanto a cómo funciona <a href="/tags/graphql">GraphQL</a>, y creo que a medida que avanzamos en el masterclass, tendremos tiempo para profundizar en algunos de estos conceptos. Y obviamente, creo que esto es realmente bueno para que te intereses en <a href="/tags/graphql">GraphQL</a>, pero aún así te recomendamos que si realmente quieres aprender, hay recursos públicos increíbles, también recursos de <a href="/tags/aws">AWS</a> que puedes utilizar

solo para comenzar y profundizar realmente en <a href="/tags/graphql">GraphQL</a>. Pero de manera muy simplificada, en su lugar, así que usemos REST como ejemplo. La forma en que describes lo que está disponible para tu API sería a través de tu contrato de interfaz, que es muy común, como un esquema de API abierto, y donde describes tus acciones permitidas, los recursos en los que puedes operar, y así sucesivamente. Con <a href="/tags/graphql">GraphQL</a>, aún tienes un contrato de interfaz. Pero la forma en que describes tus operaciones disponibles y tus recursos es en lugar de hacerlo en un esquema de API abierto, lo haces a través del esquema de <a href="/tags/graphql">GraphQL</a>. Y verás el poder que se desbloquea detrás de estas cosas. Pero si solo echas un vistazo rápido a la diapositiva que tenemos aquí, puedes ver que la forma en que describimos los tipos se parece extrañamente a cómo mapeamos los datos en nuestras bases de datos. Y aquí es donde verás que <a href="/tags/graphql">GraphQL</a> se parece realmente, es realmente bueno conectando tu motor de consultas a los datos, porque tienes esta integración más cercana, lo que simplemente facilita las cosas al final del día. Entonces, en tu esquema de <a href="/tags/graphql">GraphQL</a>, definirás cuáles son tus tipos de objetos. Entonces, si eres una persona de OOP, estos serían tus clases. Aquí tenemos un tipo de objeto libro, un tipo de objeto reseñas. Y cuando haces consultas, en lugar de hacer una ruta, un get /libros, harías una lista de libros. Y la diferencia principal es que en lugar de obtener toda esta información que un libro puede devolver, podemos seleccionar en tiempo de ejecución cuando hacemos la consulta, obtenemos solo los datos que necesitamos. Esto significa que si necesitamos, entonces esto es realmente simple, pero imagina que el libro tuviera como 50 reseñas en un sistema REST típico, obtendríamos el ID, el título del autor y luego las 50 reseñas. Tal vez si hicimos alguna paginación, se recortaría a algunos límites, pero puedes ver, podríamos obtener todo esto, podríamos tener todo este conjunto de datos. Pero, ¿qué pasa si solo necesitamos el título y el autor, porque solo necesitamos una descripción general? Estamos obteniendo datos innecesarios a través de la red, simplemente solicitando datos adicionales que no son necesarios, haciendo que las solicitudes sean más lentas porque necesitas pasar más datos por la red. Y con <a href="/tags/graphql">GraphQL</a>, no tienes que hacer eso. Simplemente puedes solicitar los datos que necesitas en tiempo de ejecución. Y cuando lo hagamos en el masterclass, tendremos algunos ejemplos reales donde podrás probar algunas de estas flexibilidades en los patrones de consulta que puedes

lograr con <a href="/tags/graphql">GraphQL</a>. Y luego, en términos de operaciones, tenemos, y esto es muy similar a cómo funciona REST, pero con nombres diferentes. Entonces, las consultas serían tus gets, tus lecturas, y tienes mutaciones para hacer cualquier cosa que implique escribir, actualizar, eliminar. Y además, tienes algo que no está en REST, al menos en la especificación, que son las suscripciones. Y esto es extremadamente útil. Es un mecanismo de publicación en tiempo real, que es realmente bueno para crear experiencias en tiempo real. Necesitas enviar <a href="/tags/data">data</a>, necesitas suscribirte y obtener actualizaciones en vivo, lo cual es común, por ejemplo, en muchos eventos deportivos donde necesitas enviar <a href="/tags/data">data</a>, la última <a href="/tags/data">data</a> disponible, para un widget específico o un conductor específico, este tipo de cosas, datos reales, obtener datos reales a través de la red. Es algo en lo que <a href="/tags/graphql">GraphQL</a> realmente destaca porque puede hacerlo a escala. Ahora, más allá de las escenas, pasemos a la siguiente diapositiva, Emmanuel. Entonces, más allá de las escenas, lo que tenemos es este esquema, que es lo que ven los clientes. Y luego vinculamos tipos a resolvers. ¿Y qué son los resolvers? Puedes pensar en los resolvers como unidades de cómputo específicamente diseñadas para obtener ese tipo específico de <a href="/tags/data">data</a>. Lo que esto significa es que para los datos del libro, podemos tener un resolver de libro, que simplemente se enfoca y está diseñado para interactuar con una tienda de datos de libros y devolverte esos datos. Al mismo tiempo, debido a la forma en que funciona <a href="/tags/graphql">GraphQL</a>, puedes ver el libro como un atributo que se reutiliza. Sin embargo, la reseña es su propio tipo. Y el resolver de libro solo se encarga de obtener información del libro. Entonces lo que sucede es que las reseñas se obtienen mediante un resolver de reseñas. La forma en que se maneja esto es que se gestiona automáticamente por el motor de <a href="/tags/graphql">GraphQL</a>, porque no necesitas hacerlo tú. Y como su nombre indica, es como un lenguaje de consulta de gráficos. Entonces, todas estas cosas, la forma en que modelas tu esquema con todas estas dependencias, todo esto, tan pronto como, siempre y cuando mapees tus tipos correctamente a las fuentes de datos, todas estas dependencias y gráficos se resolverán automáticamente en tiempo de ejecución cuando realices tus consultas. Entonces, en este caso, si solicitamos información de un libro y sus reseñas, se activará el resolver específico, obtendrá los datos de las fuentes de datos específicas y los devolverá en una única respuesta, todo de forma automática, sin uniones complejas en tu API de Express o algo así. No, todo se gestiona sin problemas para ti. Si pasamos a la siguiente diapositiva, Manu. Entonces, creo que ya hemos descrito algunas de las, esto sería una de las comparaciones técnicas entre REST y <a href="/tags/graphql">GraphQL</a>. También hay otra que es la organizativa. Y no quiero extenderme demasiado en eso, pero si lo piensas, uno de los aspectos en los que se beneficia técnicamente de <a href="/tags/graphql">GraphQL</a> en comparación con REST, también está este problema de escalabilidad organizativa, porque cuando tienes, y puedes ir a la siguiente diapositiva, Manu. Cuando estás desarrollando una REST, defines un esquema específico, defines una versión, y esto es algo que se mantiene, siguiente diapositiva, puedes, creo que puedes

ir a la siguiente herramienta, porque ya la he cubierto. Sí, exactamente. Entonces, cuando estás desarrollando en REST, defines, defines una de las primeras cosas que defines es, okay, cuál será, mi contrato de interfaz, porque esto, y esto debe ser estable. Por lo general, se adjunta a una versión para que puedas distribuir esto de manera confiable a tus clientes. Puedes tener múltiples clientes, no solo tu <a href="/tags/frontend">frontend</a>, puedes tener tal vez tu API es una API de <a href="/tags/data">data</a> que también sirve a otras aplicaciones. Por lo tanto, esta estabilidad de tu contrato de interfaz es extremadamente, extremadamente importante. De lo contrario, te encontrarás en una situación en la que tus clientes intentan acceder a algo que no está disponible. Entonces, esta planificación anticipada es extremadamente difícil y se vuelve aún más difícil a escala porque diferentes equipos tienen diferentes agendas y hojas de ruta. Y siempre es muy difícil priorizar cuando necesitas, oh, pero sé que necesito un nuevo parámetro. Necesito un nuevo recurso. Y te encuentras en esta situación en la que los equipos están limitados por la flexibilidad con la que diseñan sus APIs. Si comparas esto con <a href="/tags/graphql">GraphQL</a>, si miras la siguiente diapositiva, gracias. Sin embargo, la forma en que <a href="/tags/graphql">GraphQL</a> hace esto es intentando desvincularse de esta restricción mediante la construcción o promoción de un sistema sin versión. Esto significa que tus clientes pueden, mientras están desarrollando, inspeccionar qué es el esquema disponible. Esta es una característica extremadamente poderosa en <a href="/tags/graphql">GraphQL</a>, donde puedes obtener todos los tipos admitidos, las consultas admitidas, como las operaciones para las lecturas y escrituras. Puedes obtener esto desde tu cliente. Por lo tanto, no necesitas comunicarte y no necesitas sincronizar con un equipo específico. Oye, ¿puedes enviarme el contrato de interfaz o por qué no funciona esto ? Porque ni siquiera necesitas comunicarte. Simplemente extraes este esquema mientras estás desarrollando. Y esto hace las cosas mucho más fáciles. El hecho de que esta introspección de esquema sea una característica de introspección de esquema es lo que hizo que el equipo de <a href="/tags/graphql">GraphQL</a> dijera realmente, mira, creo que en este caso, realmente puedes impulsar APIs sin versión porque siempre sabes qué está disponible. Entonces, cada vez, lo que consumes siempre es estable. Y esto, creo que este modelo mental desarrollado es un gran cambio de paradigma entre lo que era REST y lo que es <a href="/tags/graphql">GraphQL</a> porque REST se siente, se siente, se siente como algo estable. Mientras que <a href="/tags/graphql">GraphQL</a> se siente como un sistema en evolución, que siempre está, siempre está evolucionando dinámicamente. Y luego también tienes, pero con REST una de las cosas que no diría que es peor en términos de competencia, pero es algo que debes tener en cuenta es la débil tipificación de datos en comparación con <a href="/tags/graphql">GraphQL</a>, porque asumes que el contrato de interfaz se respeta, por supuesto, pero aún así necesitas ejecutar alguna, probablemente necesitas ejecutar alguna validación en tus clientes y también en tu servicio, si estás haciendo posts o gets, pero probablemente necesites ejecutar alguna validación adicional para verificar si el tipo de <a href="/tags/data">data</a> que proviene del servidor o proviene de tus clientes son los esperados. Y con el esquema de <a href="/tags/graphql">GraphQL</a>, porque el esquema se distribuye esencialmente a ambas partes, la estabilidad, la tipificación de <a href="/tags/data">data</a> se aplica por defecto.

Entonces, es algo que no es una preocupación. Ahora, ¿qué sigue en la siguiente diapositiva, por favor? Entonces, esto cubre muy brevemente <a href="/tags/graphql">GraphQL</a> y <a href="/tags/graphql">GraphQL</a> es parte de la razón por la que estamos hablando aquí. La otra parte es mostrarte cómo podrías construir <a href="/tags/graphql">GraphQL</a> y beneficiarte de <a href="/tags/graphql">GraphQL</a>, pero dentro de <a href="/tags/aws">AWS</a>. Y afortunadamente tenemos un servicio extremadamente poderoso, tal vez sesgado, pero extremadamente poderoso para esto, que es <a href="/tags/aws">AWS</a> AppSync. Y como mencionó Emmanuel, es una implementación de la especificación original de <a href="/tags/graphql">GraphQL</a>, pero con todos los beneficios de ser un servicio administrado. Entonces, los principales beneficios son que es sin servidor, por lo que no necesitas preocuparte por la escalabilidad. No necesitas preocuparte por aprovisionar capacidad informática. Tiene integración incorporada con muchos otros servicios de <a href="/tags/aws">AWS</a>. Por lo tanto, todas estas características agradables que están integradas en el ecosistema de <a href="/tags/aws">AWS</a> están disponibles para ti al optar por <a href="/tags/aws">AWS</a> AppSync. Mientras que si quisieras construir tus propias implementaciones y resolvers de AppSync, lo cual puedes hacer, puedes hacerlo en <a href="/tags/apollo">Apollo</a>. Puedes hacerlo en, ¿cómo era? Relay, creo que era Relay. Entonces, también hay un par de implementaciones de <a href="/tags/graphql">GraphQL</a> que también son extremadamente poderosas y populares, pero carecen de este enfoque integral que AppSync promueve, donde te enfocas solo en tu lógica empresarial, que probablemente es lo que tu equipo quiere de todos modos. Entonces, si pasamos a la siguiente diapositiva, Emmanuel, la forma en que funciona AppSync, y verás que es realmente solo una implementación de <a href="/tags/graphql">GraphQL</a>, pero adaptada al ecosistema de <a href="/tags/aws">AWS</a>, pero quiero resaltar tal vez las cosas que se construyen sobre ella. Entonces, estas integraciones con algunos de los otros servicios. Entonces, las unidades de cómputo, que se llaman resolvers, las que realizan la obtención de datos a través de tus fuentes de datos y envían la solicitud de vuelta a tus clientes, son manejadas por uno de los resolvers. Actualmente, <a href="/tags/aws">AWS</a> admite dos. El primero son los resolvers de <a href="/tags/javascript">JavaScript</a> y los resolvers de <a href="/tags/javascript">JavaScript</a> están integrados en el motor de AppSync. Por lo tanto, no hay ningún cargo adicional, no necesitas preocuparte por configurar la capacidad de memoria, que a veces es lo que debes hacer con sin servidor, pero aún hay algunos parámetros de configuración. Con los resolvers de <a href="/tags/javascript">JavaScript</a>, esto no es de tu preocupación, simplemente agregas tu lógica empresarial sobre los resolvers de <a href="/tags/javascript">JavaScript</a> y esto se ejecuta automáticamente. Esta simplicidad también viene con su propio conjunto de desafíos. Entonces, los resolvers de <a href="/tags/javascript">JavaScript</a>, porque realmente están destinados a ser livianos y muy simples, no se supone que debas construir o incluir dependencias externas. Entonces, si quisieras, por ejemplo, con <a href="/tags/javascript">JavaScript</a>, si quisieras incluir dependencias de <a href="/tags/npm">NPM</a>, eso no sería posible. Sin embargo, podrías hacerlo con los resolvers de <a href="/tags/lambda">Lambda</a>. Sí, está bien. Creo que fue una buena transición. Entonces, con los resolvers de <a href="/tags/lambda">Lambda</a>, en realidad podrías, si tienes esta necesidad de, oh no, pero necesito usar esta biblioteca para hacer OpenID Connect, o una implementación de WebSockets, o no sé. Si ves que necesitas incluir tus paquetes de <a href="/tags/npm">NPM</a>, tal vez de tu equipo, <a href="/tags/lambda">Lambda</a> podría ser una alternativa, pero debes tener en cuenta lo que implica <a href="/tags/lambda">Lambda</a>. Y para aquellos que no saben qué es <a href="/tags/lambda">Lambda</a>, <a href="/tags/lambda">Lambda</a> es la función, es una función como servicio que está disponible en <a href="/tags/aws">AWS</a>. Y puedes pensar en ella como unidades de cómputo muy pequeñas y bien empaquetadas que no necesitan ningún aprovisionamiento. Y la forma en que funciona <a href="/tags/lambda">Lambda</a> es que puede escalar por miles de ejecuciones simultáneas sin que tengas que preocuparte por ello. Y admite, puedes construir Lambdas en, ¿dónde estábamos? Resolvers de <a href="/tags/javascript">JavaScript</a>. Como dice el nombre, estás limitado a <a href="/tags/javascript">JavaScript</a>. Los resolvers de <a href="/tags/lambda">Lambda</a> actualmente admiten la mayoría de los entornos de ejecución populares. Por lo tanto, puedes construir en Go, en <a href="/tags/rust">Rust</a>, en Java. Sí, Java, en <a href="/tags/javascript">JavaScript</a>. La lista está en constante crecimiento. Y es una de las soluciones de cómputo más comunes en las que las personas confían, y nuestros clientes confían, porque el costo es realmente muy bajo. Si pasamos a la siguiente diapositiva, Emmanuel, solo rápidamente, algunos de los beneficios de hacerlo sin servidor. Y creo que esto es con <a href="/tags/aws">AWS</a> AppSync, con los resolvers de <a href="/tags/javascript">JavaScript</a>, con los resolvers de <a href="/tags/lambda">Lambda</a>, todo es sin servidor. Y realmente tratamos de resaltar cuáles son los puntos clave de usar sin servidor en <a href="/tags/aws">AWS</a>. Y al final, todo se reduce a permitirte centrarte en construir lo que importa. Probablemente, sí, es importante preocuparse por la seguridad y la escalabilidad y la alta disponibilidad. Pero lo que realmente necesitas es construir esa función, y necesitas implementarla hoy, y necesitas que sea rápida, y no quieres preocuparte por tener esta carga en el frente porque solo quieres construir un POC o solo quieres probar algo. Sin servidor te brinda este poder, y no me malinterpretes, no es solo para POCs. Muchos de nuestros clientes construyen y usan <a href="/tags/lambda">Lambda</a> en producción. Entonces, sí, definitivamente es escalable hasta cierto punto. Ahora... Diría que tal vez... En este punto cambiaremos a la masterclass, a la parte práctica. Solo quiero preguntar si hay alguna pregunta antes de hacer la transición a eso. Si no, pasaremos directamente a ello. Tal vez podamos revisar el chat. De acuerdo, lo tomaré como un no. Siempre puedes hacer preguntas en el chat también. Dicho esto, también lo publicaré en el chat para que puedas iniciar sesión. Tal vez necesito dejar de compartir por un segundo. De todos modos, no necesitaremos las diapositivas a partir de aquí, así que pondré un enlace en el chat y luego el código de acceso. Una vez que ingreses a ese enlace, te pedirá que te registres. Puedes usar la primera opción, que es el código PIN de un solo uso que se enviará a tu correo electrónico. Y después de hacer eso, podrás iniciar sesión en la masterclass en sí. Exactamente. Esta es la primera pantalla que verás. Entonces, harás el correo electrónico y la contraseña de un solo uso. Una vez que lo recibas en el correo electrónico, puedes iniciar sesión. Y después de eso, deberás ingresar este código PIN que acabamos de darte en el chat, y luego podemos comenzar. Por favor, escribe en el chat cuando estés listo para que podamos continuar. Te daremos tal vez cinco minutos para esa parte, y luego comenzaremos con la parte práctica. Y como mencioné, no será necesario instalar nada en tu computadora

un entorno virtual donde podemos trabajar. Sí. Y si prefieres solo escuchar, porque vamos a ir paso a paso en la masterclass. Así que si prefieres mantener las manos libres y hacerlo más tarde, también es una posibilidad. Si quieres hacerlo como lo hacemos nosotros, también está bien. Creo que vamos a ir lo suficientemente despacio como para que todos puedan seguir el ritmo. Así que creo que estará bien.Ahora viene la parte interactiva de la presentación. Ahora que ya te hemos presentado a nuestra introducción a Databrief en <a href="/tags/graphql">GraphQL</a>, en AppSync, vamos a poner manos a la obra, que creo que siempre es la parte interesante. El sitio que vamos a construir, curiosamente, Emmanuel hizo la referencia. No sé si fue al azar o no, sobre Netflix y el motor de recomendación. Es curioso porque en realidad estamos construyendo un sitio web de recomendación de libros completamente con <a href="/tags/aws">AWS</a>. Así que vamos a utilizar un par de servicios. Verás cuál es el catálogo de servicios que vamos a utilizar, pero estará muy centrado en AppSync. Sí, la página que ves aquí es lo que vamos a construir. Bueno, en realidad no, no vamos a desarrollar el <a href="/tags/frontend">frontend</a> y los widgets, pero vamos a tener algunas funcionalidades predefinidas para algunas partes de la aplicación y simplemente vamos a mostrar cómo podrías luego construir las interacciones con <a href="/tags/graphql">GraphQL</a> en el lado del cliente. También en el lado del servidor, vamos a construir una API de AppSync. Vamos a construir autenticación sobre ella. Y vamos a cubrir tanto el esquema de la API como todas las operaciones. Así que vamos a hacer ambas cosas. Vamos a cubrir consultas. Vamos a cubrir mutaciones. Así que operaciones de escritura. Y también vamos a hacer si tenemos tiempo, vamos a hacer la funcionalidad en tiempo real. Así es como puedes utilizar las suscripciones de <a href="/tags/graphql">GraphQL</a> para crear interfaces de usuario reactivas que sean impulsadas por AppSync.Si pasamos a ver, o si echamos un vistazo rápido a alto nivel a la arquitectura que vamos a implementar, esto es lo que parece. En realidad es bastante simple. Así que en el lado del cliente, tenemos algunos clientes web, móviles. Lo que vamos a utilizar para ayudarnos a construir la conexión y la integración con AppSync y también con algo de autenticación. Vamos a utilizar Amplify. Amplify es tanto un servicio como una biblioteca, una biblioteca y servicio de <a href="/tags/aws">AWS</a> que te ayuda a construir aplicaciones web y no solo construir aplicaciones full stack, sino enfocarse en web y móvil. Y realiza muchas de las tareas que normalmente no quieres o no te importan demasiado porque no se centran en tu negocio. Cosas como configurar un pipeline de <a href="/tags/ci-cd">CI</a>/<a href="/tags/ci-cd">CD</a>, construir y transpilar tu código, manejar conectores para autenticación. Estas cosas están incluidas en Amplify y luego puedes usar la biblioteca del lado del cliente para conectar estas características a estos servicios automáticamente. Así que simplifica las cosas. Desde una perspectiva de autenticación, vamos a utilizar dos métodos para la autenticación hoy. Vamos a utilizar claves de API y vamos a utilizar los flujos tradicionales de identidad de usuario. Así que vamos a utilizar tokens JWT basados en OAuth. Y vas a entender cuándo vamos a utilizar cada tipo de método de autenticación, porque vamos a hacer algo interesante. Luego, en la entidad que validará la autenticación. Para la clave de API, esa clave de API vivirá como parte de <a href="/tags/graphql">GraphQL</a> de AppSync. AppSync realiza esa autenticación por sí mismo, pero para validar los tokens JWT, vamos a utilizar Amazon Cognito y Amazon Cognito, nada más que la oferta de <a href="/tags/aws">AWS</a> ADP. Así que es algo que, si lo estuvieras construyendo tú mismo, no necesariamente estarías atado a Cognito. Podrías utilizar tu proveedor de identidad de terceros o el proveedor de identidad de tu organización y seguiría funcionando porque AppSync proporciona estos tipos de integraciones. Luego, si miramos en el lado posterior de las cosas, vamos a tener un conjunto de resolvers, que lo que harán, como expliqué antes, es simplemente extraer datos de las fuentes de datos y hacer que se ajusten al esquema que está disponible para tus clientes. Así que el almacén de datos que vamos a utilizar es Amazon DynamoDB. Para aquellos que no lo saben, Amazon DynamoDB es la oferta de Amazon de una base de datos NoSQL. Tiene su propia especificación, tiene sus propias características. Así que creo que es una base de datos NoSQL, tiene su propio conjunto de características y la forma en que está diseñada, Amazon DynamoDB es un almacén de datos de clave-valor, está realmente enfocado y está optimizado para búsquedas de clave-valor a escala para millones de registros. Siempre y cuando esté diseñado e implementado correctamente, por supuesto, pero se adapta muy bien a nuestro caso de uso porque necesitamos construir un catálogo de servicios. Probablemente necesitemos consultar uno o varios libros de nuestra librería. DynamoDB será nuestra librería. DynamoDB encaja muy bien en este caso de uso también. Y también tienes el beneficio de ser otro servicio sin servidor. Así que no necesitas preocuparte por la memoria, por la capacidad. Puedes utilizar, puedes beneficiarte de los modos bajo demanda de DynamoDB y simplemente preocuparte de asegurarte de que los datos estén disponibles para tus. Así que creo que estamos listos para empezar. Creo que di suficiente contexto. Vamos a empezar construyendo lo que trata la masterclass. Así que vamos a empezar construyendo AppSync. Y estas primeras secciones, en realidad vamos a construir, vamos a estar aprovisionando los servicios. Vamos a construir los fundamentos. Y luego, a medida que establecemos esta base, podemos realmente empezar a probar y hacer consultas para que puedas entender cómo podrías, para qué tipo de casos de uso podrías realmente utilizar <a href="/tags/graphql">GraphQL</a>. Así que la primera parte con el diseño de una API, <a href="/tags/graphql">GraphQL</a>, REST, creo que los contratos de interfaz

El <a href="/tags/graphql">GraphQL</a> siempre debería ser tu enfoque principal. En <a href="/tags/graphql">GraphQL</a>, porque tienes esta idea de un sistema sin versión, siempre puedes evolucionar tu esquema, pero es importante que lo modelas adecuadamente porque esto puede tener un impacto no solo en el rendimiento, sino también en la organización. Por lo tanto, el tipo en el que quiero que nos enfoquemos aquí es el tipo de libro. Así que vamos a tener un objeto de tipo libro. Aquí puedes ver un conjunto de atributos, y luego estos atributos tienen tipos. Los tipos en <a href="/tags/graphql">GraphQL</a> se llaman tipos escalares, porque tienes un conjunto muy limitado de tipos disponibles. La lista completa de escalares está disponible en esta cosa, pero en realidad solo quiero cubrir aquí los que están aquí, porque cubren la mayoría de los casos de uso. Tienes cadenas de texto, enteros, IDs. Las IDs son como cenizas únicas, que son muy adecuadas para IDs específicas o únicas. Y luego puedes ver aquí que tienes este signo de exclamación, y esto es básicamente una sintaxis para especificar que estos atributos son requeridos. Todo lo que no incluye esto significa que es opcional, pero si lo incluye, es requerido. Otra cosa aquí, creo que esto, puedes adivinarlo, es una lista, por lo que es un array de géneros. Entonces, lo que vamos a hacer es, y tal vez esto es importante, dos cosas que necesitamos aclarar. Todo lo que vamos a cubrir en esta masterclass, lo haremos a través de la consola de <a href="/tags/aws">AWS</a>, simplemente porque es más simple y más visual para ti, así que creo que es más fácil para que puedas seguir. Sin embargo, obviamente puedes usar <a href="/tags/cdk">CDK</a>, Terraform, cualquier tipo de tu infraestructura como código de preferencia. Definitivamente puedes hacerlo, pero aquí por razones de simplicidad, vamos a usar la consola. También obtienes algunos beneficios al usar la consola porque los equipos de servicios de <a href="/tags/aws">AWS</a> han puesto mucho esfuerzo en crear asistentes de configuración que hacen mucho por ti.

detrás de escena, y lo verás. Y esta es la primera información importante. La segunda es, cuando abras tu cuenta aquí, debes estar en EU West1. De acuerdo, para que todos podamos crear nuestra API, debemos navegar a esta página, así que solo necesitamos hacer clic en ella y se abrirá automáticamente, con suerte. Y luego debes estar en Irlanda, porque la masterclass está configurada para Irlanda, así que asegurémonos de que todos nuestros servicios regionales estén en la misma región. Para crear la API de AppSync, no sé para aquellos que no están familiarizados con <a href="/tags/aws">AWS</a>, no se preocupen. Solo vamos a usar la barra de búsqueda. Creo que es sencillo, así que queremos ir a <a href="/tags/aws">AWS</a> AppSync, y obtendrás este botón porque aún no hemos creado ninguna AppSync, ninguna API todavía, así que vamos a utilizar este asistente de configuración, y esto es lo que estaba diciendo sobre el equipo de servicio que se esfuerza mucho para asegurarse de que el proceso de creación sea simplificado. Lo que queremos seleccionar es, no queremos cubrir APIs fusionadas. No las vamos a cubrir en esta masterclass. En realidad, es una de las secciones avanzadas, así que si tenemos tiempo, sería genial revisarla, pero si no, aún puedes hacerlo después de la sesión, pero solo vamos a hacer APIs regulares de <a href="/tags/graphql">GraphQL</a>. Para aquellos que tienen experiencia en <a href="/tags/graphql">GraphQL</a>, las APIs fusionadas son una opción para la unión de esquemas, pero en tiempo de compilación, es algo de AppSync. En lugar de realizar la unión en tiempo de ejecución de los esquemas de diferentes sub APIs de <a href="/tags/graphql">GraphQL</a>, simplemente lo compilas en una sola API para toda tu organización o proyecto, así que es una característica realmente poderosa. Hay un par de casos de uso. Así que vamos a diseñ<a href="/tags/vr-and-ar">ar</a>. Vamos a elegir la opción de diseñ<a href="/tags/vr-and-ar">ar</a> desde cero, y vamos a llamar a nuestra API Books API. No nos preocuparemos por las APIs privadas, así que mantendremos nuestra API pública. Sin embargo, esta sería una posibilidad si quisieras que tu API solo sea accesible a través de una VPC o si quisieras restringirla a tu organización, es algo que podrías hacer. Aquí puedes ver que puedes asociarla a una VPC. Tal vez debería explicar qué es una VPC. Para simplificarlo, puedes pensar en ello como tu propia red privada. Puede ser una red corporativa, como si trabajas en una empresa, pero también puede ser algo privado que tal vez no quieras compartir con el mundo. Entonces, tal vez estás construyendo APIs dentro de otras APIs, combinas todo eso y solo expones tal vez la API final al orquestador, tal vez al final a la aplicación. Es solo una forma de mantener las cosas, digamos, no todas en Internet público. Gracias, Emmanuel. Gracias. Para el tipo <a href="/tags/graphql">GraphQL</a>, lo que vamos a usar aquí, porque estamos utilizando una tabla de DynamoDB, en realidad vamos a utilizar esta opción para obtener automáticamente una tabla de DynamoDB asociada a la API de <a href="/tags/graphql">GraphQL</a>. Y verás que detrás de escena, esto creará tanto la base de datos como el esquema de forma automática según el modelo, según el modelo de datos que definamos. Así que esto es bueno tenerlo. Y nuestro modelo es libro, ¿verdad? Estamos construyendo objetos de tipo libro y luego los campos aquí realmente puedes copiarlos. Estos serán los, puedes ver aquí que estos atributos coinciden con el modelo de datos que tendremos en el esquema. Así que tenemos el ID, título, autor, puedes ver todos estos tipos de campos. Y puedes ver aquí que son requeridos y no requeridos. Así que vamos a completar todos estos campos en la consola. Puedes hacerlo a tu propio ritmo. Mientras lo haces, tal vez puedas proporcionar un poco de explicación, ¿verdad? Esto es probablemente un paso crucial cuando diseñas este tipo de APIs, ¿verdad? Necesitas pensar en cuál es tu modelo de datos y quieres modelarlo adecuadamente porque de lo contrario más adelante, será un poco más difícil cambiarlo. Es posible, pero estará directamente vinculado al esquema también. Esto sería, y luego cuando analices tu problema, debes considerar cuál es el dominio, qué dominio cubre esta API y luego modelarlo en consecuencia. Porque verás que esto es, entonces, DynamoDB, es una base de datos, es una base de datos NoSQL, pero aún tiene cosas como índices, tiene cosas como claves primarias. Así que será relevante hacerlo bien. Seguro. Sí, esto es algo que, gracias Emmanuel. Pero cuando pienso en Dynamo, especialmente DynamoDB está diseñado para casos de uso en los que realmente comprendes tus datos y cómo consumirás los datos. Y si lo haces correctamente, puedes extraer el máximo rendimiento de tu, de esta base de datos. No es realmente una base de datos de propósito general que funcione para todo tipo de casos de uso. Al menos <a href="/tags/aws">AWS</a>, intentamos impulsar la tecnología y las bases de datos diseñadas para un propósito específico. Y DynamoDB, realmente tienes que comprender qué tipo de patrones de acceso están asociados a tu aplicación para poder diseñ<a href="/tags/vr-and-ar">ar</a> un modelo que tenga sentido desde una perspectiva empresarial, pero también desde una perspectiva tecnológica. Dicho esto, no es necesario utilizar DynamoDB. Puedes utilizar cualquier tipo de base de datos SQL, ya sea Postgres o MySQL. Puedes utilizar cualquiera de ellas. No es un requisito. Es solo para este ejemplo que utilizamos DynamoDB porque es <a href="/tags/serverless">serverless</a> y es fácil de aprovisionar y no es necesario esperar a que se inicie un servidor en media hora. O no sé, dependiendo de qué tan grande sea. Y sin importar si utilizas SQL o NoSQL, un poco de modelado de datos es necesario. Veo una pregunta de Christophe que pregunta, ¿puedes configurar el modelo con CloudFormation? Creo que encontrarás en la misma masterclass allí, encontrarás la variante de <a href="/tags/cdk">CDK</a>, que es básicamente una forma más inteligente de hacer CloudFormation. Así que sí. Entonces, tal vez si dices el modelo de datos, el modelo de <a href="/tags/graphql">GraphQL</a>, no, no debes hacerlo con CloudFormation simplemente porque normalmente usamos CloudFormation para definir los recursos de <a href="/tags/aws">AWS</a>. Y cuando defines, creas tu API de AppSync con CloudFormation, pero la configuración real debe definirse en su propio archivo. Así que hay un archivo de especificación, un archivo de configuración para el <a href="/tags/graphql">GraphQL</a>. Y esto es lo que usarías para definir tu modelo de datos. Y luego lo adjuntarías a tu recurso de CloudFormation, si tiene sentido. Muy bien. Espero haber dado a todos suficiente tiempo para completar estos campos. Ahora que tenemos esto, este será el plan para construir nuestro bot. Nuevamente, dije nuevamente, repitiéndome, pero la tabla de DynamoDB y el esquema de <a href="/tags/graphql">GraphQL</a>, verás cómo sucede esto detrás de escena. Obviamente, si lo estás construyendo tú mismo, tendrías que hacerlo por separado. Y luego para el tiempo de ejecución del resolutor, aquí tenemos dos opciones. Por lo general, la opción que recomendamos es AppSync simplemente porque está más actualizado y es un tipo de tiempo de ejecución que actualmente recibe más atención del equipo de servicio en términos de nuevas funciones que generalmente se lanzan primero en este tipo de tiempo de ejecución. Así que esta es generalmente la que recomendamos para nuestros clientes. Miguel, tienes un tipo o un error en Java. Debería ser un array de cadenas.

Gracias. No, pero sí. No, sí. No vi esta columna de array. No, sí. Gracias. Creo que ahora está todo bien, ¿verdad? Creo que sí. No cambia mucho, ¿verdad? En términos de, pero para que estemos en la misma página. Sí, se notaría en el esquema de inmediato, pero sí, buena observación. Entonces, para el nombre de la tabla, la llamaremos. Intentaré seguir el ejemplo para que sea consistente para todos. Y aquí hablando de clave primaria, clave de ordenamiento para todos los que están familiarizados o no están familiarizados con esta idea de clave primaria y clave de ordenamiento. Una clave primaria funciona como en las bases de datos relacionales en el sentido de que identifica de manera única un registro para tu <a href="/tags/database">database</a>. Y luego la clave de ordenamiento es específica de DynamoDB en el sentido de que puedes usar una clave primaria en una clave de ordenamiento para crear la clave compuesta. También tienes la idea de claves compuestas como en las bases de datos relacionales, pero los casos de uso para las claves de ordenamiento en DynamoDB son algo diferentes. Y tal vez puedas ayudarme aquí, Emmanuel, porque me faltan las palabras. Entonces, con las claves primarias, las usarás cuando necesites obtener registros específicos. Y con las claves de ordenamiento, puedes hacer otros tipos de consultas basadas en expresiones filtradas o expresiones de rechazo. Lo siento, tuve que quitarte el silencio. Sí, definitivamente. Entonces, las claves primarias, como en cualquier otra <a href="/tags/database">database</a>, simplemente puedes obtener ese elemento específico mediante la clave primaria en sí misma. Con la clave de ordenamiento, puedes pensar en ello como si tuvieras tu tabla y tienes tu clave primaria. Y cuando agregas una clave de ordenamiento, puedes encontrar ese elemento específico dentro de ese espacio específico. Entonces, digamos que podrías tener una clave primaria de mascotas y podrías tener una clave de ordenamiento relacionada con geografías, ¿verdad? Entonces, puedes hacer consultas súper eficientes buscando mascotas en, digamos, Alemania o no sé, lo que sea que tengas. Así que espero que eso te dé una idea de cómo funcionaría. Gracias. Y esto sería esencialmente la forma predeterminada de consultar tu <a href="/tags/database">database</a>. Cada vez que quieras interactuar con tu <a href="/tags/database">database</a>, tendrías en el caso que no incluirá ninguna clave de ordenamiento. Así que siempre tendrías que proporcionar esta clave primaria. Y esto es algo que, por <a href="/tags/creativity">design</a>, con DynamoDB siempre necesitas proporcionar una clave primaria. Y luego tenemos esta idea de índices. Y esto, nuevamente, toma el mismo concepto de los índices en las bases de datos relacionales. Pero en DynamoDB, funciona de manera ligeramente diferente porque, o funciona de manera similar, en el sentido de que te permite formas de consulta de <a href="/tags/data">data</a>, pero para diferentes patrones de acceso. Entonces, de forma predeterminada, en el predeterminado, el predeterminado, se espera que consultes <a href="/tags/data">data</a> por tu ID de libro. Y estamos agregando índices adicionales para facilitar las consultas por ID de autor y también por editor. Entonces, ID del editor. Y luego no vamos a usar ningún ordenamiento para mantenerlo simple. A continuación, creo que en este punto podemos hacer un breve resumen de todo lo que hemos pasado. Diseñamos una API desde cero. Especificamos el nombre de nuestra API. Decidimos que queríamos crear una tabla de DynamoDB de inmediato para que esté presente. Esto será útil porque generará muchas cosas para nosotros. Especificamos nuestro modelo de <a href="/tags/data">data</a>, y especificamos algunos detalles sobre nuestro conjunto de datos. Con esto dicho, ahora estamos listos para proceder a crear y esperar. Mientras esperamos, creo que tomará unos 10 segundos más. Lo que está sucediendo detrás de escena es que todo lo que acabamos de pasar, se va a aprovisionar. Así que tendremos una tabla junto con la API funcionando juntas. Y creo que justo después de esto, podrás ejecutar esencialmente tus primeras consultas. Por supuesto, una vez que actualicemos, probablemente el esquema. Entonces, y verás durante el resto de la masterclass, lo fácil que fue crear nuestra primera API sin tener que esperar minutos u horas o lo que sea. Y ¿qué podemos hacer con esta elegante API que acabamos de crear? Sí. Y solo quiero mostrártelo rápidamente, ambos recursos. Así que puedes ver que la tabla de libros ya está creada y puedes ver... Lo siento. No hay nada en ella. Sí. Sí. Ahora puedes ver aquí que los atributos están definidos como parte de la tabla. Y al mismo tiempo, nuestra API, puedes ver aquí que ya está disponible. Así que ya es accesible. Y lo siguiente que tenemos que hacer es actualizar el esquema. Porque uno de los casos de uso que necesitamos que nuestra recomendación de libros admita es que, sí, esto, idealmente, o cada vez que creamos una... Agregamos un nuevo elemento a, o una nueva recomendación de libro a nuestra aplicación. Tenemos que proporcionar este identificador único para el libro. Y si consideramos esta idea como un ISBN, como un número de libro único, tenemos... Eso podría ser una situación en la que queremos traer ese ID de libro y no queremos que se genere. Entonces, si estuvieras construyendo tu aplicación, por lo general generas estos IDs a medida que los creas en tu <a href="/tags/database">database</a>. Pero aquí también queremos extender al escenario donde podrías traer ese ID. Entonces, una de las cosas que cambiaremos aquí es que para este input, y ¿qué es un input? Un input es otra definición o otra definición para nuestro esquema que, como sugiere el nombre, es un tipo de objeto utilizado para consultas y mutaciones.

Entonces, ¿qué es un tipo está más asociado a cómo está conectado en el <a href="/tags/backend">backend</a>, en el almacén de datos? El input puede ser ligeramente diferente. Y esta separación tiene sentido, porque muchas veces la forma en que ves los datos o la forma en que consultas los datos no necesariamente se traduce en cómo se almacenan. Así que estas separaciones simplemente mantienen las cosas ordenadas.Y lo que queremos hacer aquí es básicamente agregar la posibilidad de que cuando crees un libro, puedas proporcionar este ID. Ese es el único cambio que estamos haciendo, al menos por ahora. Tal vez puedas volver al esquema y desplazarte un poco hacia arriba aquí.Claro.Exactamente. Así que solo quería decir que en este tipo de libro, por ejemplo, también podrías tener subtipos.Podrías tener un libro y luego podrías tener... En lugar de tener el ID del autor, podrías tener un tipo llamado autor, que sería su propio tipo con nombre, no sé, la persona, de dónde es, de qué país, etc. Podrías hacer algo así.Y luego, en el input del libro, esencialmente tendrías... Podrías pasar toda esa información y <a href="/tags/graphql">GraphQL</a> se encargaría de almacenar esos detalles en diferentes almacenes de datos.Podrías tener, por ejemplo, una tabla de DynamoDB para los libros y otra tabla para los autores.Y básicamente podrías almacenar eso en diferentes cosas en el <a href="/tags/backend">backend</a>, pero desde la perspectiva del usuario, ellos no ven eso. En nuestro caso, tenemos las cosas bastante simples.Así que no necesitamos preocuparnos por eso. Pero ese sería el caso de uso donde podrías hacer esto, teniendo estas separaciones de tipos y haciendo tipos compuestos encima de eso.Creo que en la presentación, teníamos un ejemplo con publicaciones de usuarios, comentarios, etc.

Sí, exactamente. Aquí es donde entra en juego la idea de los grafos. Sí. Bueno, fue bien, fue bien. No, creo que podemos pasar a la siguiente sesión, la siguiente sección. Así que casi hemos terminado de configurar nuestra API. Lo último que tenemos que hacer es <a href="/tags/automated-security">security</a>. Y nos tomamos <a href="/tags/automated-security">security</a> muy en serio en Amazon. Entonces, hasta ahora, si quisiéramos exponer nuestra API, cualquiera podría simplemente venir y crear libros, cambiarlo. Así que queremos agregar un control de acceso. Y especificamos al principio que queríamos hacerlo de dos formas. Agregar claves de API y también tokens JWT. Y tal vez podamos comenzar con la clave de API porque es más sencillo. AppSync proporciona esta posibilidad de agregar su clave de API, por lo que no necesita mantenerla en un almacén secreto o en algún lugar seguro. AppSync proporciona este almacén para que pueda administrarlo aquí. Y la forma en que puede crear la aplicación, el masterclass debería crear una clave de API, pero es posible que vea cierto retraso. Entonces, lo que puede hacer para facilitar las cosas es crear una usted mismo y verá lo sencillo que es. Lo importante de mencionar tal vez sobre esta clave de API, al igual que todas las claves de API de hecho, es que las claves de API deben usarse con cuidado porque muchas veces es realmente difícil... Una vez que das, si alguien obtiene esta clave de API, realmente pueden perturbar y abusar de tu aplicación, pueden causar daño. Entonces, la forma en que proteges tu clave de API es extremadamente importante. Hay muchas formas de reducir la superficie de ataque, por lo que puedes usar la rotación de claves de API, el cifrado para asegurarte de que el acceso a estas claves de API esté realmente limitado. Entonces, hay muchos <a href="/tags/automated-security">security</a> controles que vienen como una responsabilidad cuando se usan claves de API, pero a veces es necesario. En ciertos casos de uso, es posible que desee tener tal vez un uso de administrador, puntos finales de administrador o tal vez durante las etapas iniciales de desarrollo donde aún no tienes tu IDP conectado. Puede ser útil usar claves de API, solo ten en cuenta que generalmente es algo que debe tomarse con mucho cuidado en producción, en sistemas de producción. Esto en sí mismo proporciona la autorización de la clave de API. Sin embargo, y al mismo tiempo, hace dos cosas porque no solo creamos una clave de API, sino que al crear una clave de API, definimos los nodos de autorización primarios porque no teníamos ninguna otra configuración. Entonces, lo que esto define básicamente es que ahora, si intentas consultar nuestra API y no proporcionas esta clave de API, serás rechazado. Por sí mismo, es mejor que no agregar nada, pero vamos a explorar algunas opciones más para asegurar la API. Así que aquí tienen la posibilidad de, tal vez, tener una descripción agradable para su clave de API. No es obligatorio, pero sí es agradable tenerlo. Ahora, pasemos al segundo método de autenticación, y aquí vamos a hablar de Cognito. Entonces, con Cognito, vamos a reproducir básicamente el comportamiento de un IDP en los datos que proporcionamos, pero utilizando tecnología integrada. Entonces, lo que Amazon proporciona es que simplifica este proceso de autenticación para ti. También, la administración de usuarios, si deseas ejecutar alguna autorización. Hay controles integrados que hacen que Amazon Cognito sea realmente bueno si necesitas algo rápido, y que proporciona una integración estrecha con algunos servicios de <a href="/tags/aws">AWS</a>. Por lo tanto, se integra muy bien con la mayoría de los servicios de API de <a href="/tags/aws">AWS</a> y vamos a crear un grupo de usuarios. Entonces, si vamos y usamos la barra de búsqueda y vamos a Cognito, tal vez vayamos a una pestaña separada, pero si vamos a Cognito, vamos a crear un grupo de usuarios. ¿Y qué es un grupo de usuarios? Es simplemente una lista de usuarios. Es tu almacén de usuarios personalizado para tu aplicación. Y nuevamente, puedes usar el asistente de configuración para facilitar las cosas. Tal vez me gustaría agregar algo aquí. La razón principal por la que queremos hacer esto es porque al final del día, queremos integrar nuestra API en una aplicación, ¿verdad? Entonces, los usuarios necesitan tener una forma de registrarse, iniciar sesión y registrarse, ¿verdad? Y usamos Cognito aquí, pero esto podría reemplazarse por cualquier cosa como Okta u Othero, o cualquier cosa con la que ya estés familiarizado o también desde <a href="/tags/azure">Azure</a>, el <a href="/tags/azure">Azure</a> AD. Funciona, es solo una implementación de la especificación OIDC. Al igual que AppSync es una implementación de la especificación <a href="/tags/graphql">GraphQL</a>. Nada específico, solo usamos este aquí para hacer las cosas súper simples. Pero funcionará con cualquier otro IDP con el que estés familiarizado. Sí, sí. Muy bien señalado. Sí, porque esta va a ser una API orientada al usuario. Entonces tiene sentido tener algún tipo de flujo de usuario. Gracias. Vamos a usar los valores predeterminados del masterclass. No quiero entrar demasiado en detalle sobre por qué elegimos nombre de usuario, por qué correo electrónico del usuario, porque en realidad no es demasiado relevante. Pero tal vez haya algunas secciones que son relevantes en esto. En esas nos vamos a enfocar, o vamos a dedicar un poco más de tiempo. La política de contraseñas, no nos vamos a preocupar por la política de contraseñas ahora. MFA, mantengamos MFA fuera nuevamente por simplicidad, para nuestros propósitos de demostración, definitivamente se recomienda en producción habilitar cualquier tipo de autenticación multifactorial, especialmente si tienes acceso a datos confidenciales o operaciones críticas. ¿Y qué tenemos aquí? Creo que vamos a usar solo el correo electrónico. Entonces, aquí en este menú, creo que puedes hacer clic en cualquier cosa antes de que todo se configure por defecto. Y luego, en la experiencia de registro, vamos a habilitar el registro automático. Nuevamente, aquí, no estamos cambiando nada. Vamos a mantener los atributos IDC predeterminados. Sí, así que en la experiencia de registro, tampoco vamos a cambiar nada. Tal vez en el mensaje, es importante señalar. Aquí, vamos a cambiar algo. Entonces, en lugar de usar Amazon SES, vamos a usar Cognito. Y la razón por la que vamos a hacer esto es por simplicidad, pero ten en cuenta que esto realmente no se recomienda para cargas de trabajo de producción. Entonces, si quieres usar Cognito como grupos de usuarios cognitivos para autenticar a tus usuarios, probablemente deberías usar el enfoque recomendado con un servicio más escalable. Aquí puedes ver que con Cognito, en realidad estás limitado a 50 correos electrónicos al día, lo cual puede no ser escalable para tu

aplicación. Pero si solo estás haciendo una pequeña POC, sería totalmente aceptable. Y ahora al nombre del grupo de usuarios. ¿Cómo vamos a llamar a nuestro grupo de usuarios? Es importante que escribas exactamente lo mismo y OK sensible porque esto se utilizará más adelante en el <a href="/tags/frontend">frontend</a>. Así que es importante que tengamos los mismos nombres aquí. Gracias. Sí. De lo contrario, probablemente necesitaríamos cambiar algo en la aplicación, ¿verdad? Entonces, en el cliente de la aplicación inicial, no vamos a cambiar nada. Vamos a mantener los clientes públicos porque estas aplicaciones serán utilizadas por aplicaciones web. Esto básicamente significa que en lugar de utilizar los flujos para clientes confidenciales donde puedes iniciar sesión de forma segura con tus credenciales, esto básicamente significa que no podrás hacerlo y utilizarás este tipo de tokens de acceso, que expiran después de un par de horas. No quiero entrar demasiado en detalle sobre OAuth aquí, para ser honesto. Y luego en los clientes de la aplicación, los clientes de la <a href="/tags/workshop">workshop</a>, en los[700] flujos de autenticación, queremos seleccionar una contraseña de usuario. Este será nuestro método de autenticación. No vamos a cambiar los valores predeterminados de TTL del token de actualización o TTL del token de acceso. Vamos a mantener los valores predeterminados. Y creo que eso es todo. Sí. Así que espero que todos estén al día o no se hayan quedado atrás. Vamos a hacer un resumen rápido para asegurarnos de que todo esté bien. Sí, está bien. Si estás satisfecho con el resultado, simplemente puedes presionar crear grupo de usuarios. Y nuevamente, con todos los servicios de <a href="/tags/aws">AWS</a>, como con la mayoría de los servicios de <a href="/tags/serverless">serverless</a> de <a href="/tags/aws">AWS</a>, esto se gestiona automáticamente para ti. Y ya puedes ver que el grupo de usuarios ya está disponible. Ya está disponible para ti. Y la última parte de esta sección es que vamos a crear un usuario para nosotros mismos. Así que vamos a crear un usuario para nosotros mismos. Vamos a crear un usuario para nosotros mismos, porque esto es lo que usaremos para probar el flujo de extremo a extremo entre nuestra aplicación y nuestra API. La forma en que puedes crear el usuario, aunque creo que teníamos un flujo de autoregistro, vamos a usar simplemente la consola de <a href="/tags/aws">AWS</a> para facilitar las cosas. Y es muy importante que envíes una invitación por correo electrónico. Y estoy bastante seguro de que solo necesitas un correo electrónico. Tal vez usemos el sugerido por la <a href="/tags/workshop">workshop</a>. Así que el correo electrónico es lo importante porque ahí recibirás la contraseña temporal para iniciar sesión. Luego se te pedirá que la actualices. Esto se generará automáticamente para ti. Alternativamente, también puedes establecer la contraseña para que puedas mantener los datos de correo electrónico solo para que tengamos algo de tiempo, pero depende totalmente de ti. De todos modos, tendrás que cambiar la contraseña. Ya sea que establezcas tu propia contraseña, pero tal vez sea difícil encontrar una contraseña que cumpla con los requisitos. De lo contrario, puedes dejar que se genere una. Y eso se enviará por correo electrónico. Y una vez que inicies sesión por primera vez, tendrás que cambiarla de todos modos. Pero sí, sigamos la <a href="/tags/workshop">workshop</a> aquí. Y ya puedes ver que el usuario ya está disponible. Entonces, una de las cosas interesantes que en realidad no vamos a cubrir en esta <a href="/tags/workshop">workshop</a> es que hay más en Cognito que se invoca al tener a tus usuarios aquí. Entonces, también podrás incluir algunas, o implementar algún tipo de autorización más avanzada, que no vamos a cubrir aquí. Solo vamos a hacer una autorización básica basada en la identidad, pero podrías incluir tus roles, tus atributos y comenzar a construir sistemas de autorización complejos. Esto es algo que sería posible con Cognito y con cualquier otro IDP, para ser honesto, pero sí, solo quería señalarlo, y esto concluye la parte de configuración. Pero en este punto, tenemos todo en su lugar. Así que solo tenemos que hacer un resumen. Necesitamos actualizar el modelo de datos. Sí. Ah, sí, cierto. Necesitamos actualizar el modelo de datos. Eso es muy cierto. Porque una de las cosas que olvidé. Gracias por recordármelo. Entonces, si queremos actualizar el modelo de datos porque queremos probar algo específico, recuerda el modo de autorización que definimos para nuestra API. Ahora mismo solo tenemos la clave de API. Entonces, todas las operaciones disponibles en nuestra API están autorizadas por la clave de API. Sin embargo, una de las cosas que queremos simular aquí es múltiples modos de autorización porque algo que AppSync admite y el flujo que queremos simular aquí es que para crear libros, necesitarías identificarte como usuario. Y si solo estás intentando realizar operaciones de lectura o simplemente obtener el catálogo de libros o realizar cualquier otro tipo de operación de lectura, entonces podrías usar la clave de API. Y esto es fácilmente alcanzable con AppSync porque puedes conectar varios modelos de autorización. De hecho, quiero cubrirlos antes de profundizar. Así que ya hemos hablado de las claves de API. El siguiente, que vamos a usar, son los grupos de usuarios de Cognito. Esto significa que vincularía tu identidad a Cognito. Se espera que proporciones algún tipo de identidad. Esto estará en forma de un token JWT. Y también tenemos otros tipos de autorizaciones, otros modos de autorización que no vamos a cubrir aquí. Así que tenemos <a href="/tags/aws">AWS</a> <a href="/tags/lambda">Lambda</a>, y esto es muy común, lo usamos mucho con nuestros clientes porque te proporciona una opción de autorización personalizada. Entonces puedes construir sobre tu IDP, ejecutar diferentes autorizaciones

basadas en qué datos se solicitan, por quién y en qué momento. Por lo tanto, puedes construir con <a href="/tags/lambda">Lambda</a>, puedes hacerlo tan complejo como desees. Y luego tienes métodos de autorización más tradicionales y simplificados. Por ejemplo, puedes usar IEM y con IEM (Identity and Access Management), puedes asegurar tu API utilizando las firmas de IEM de <a href="/tags/aws">AWS</a>. Esto significa que es muy común para aplicaciones que no son de cara al usuario, sino para comunicación entre servicios, donde tal vez el otro servicio también sea un servicio de <a href="/tags/aws">AWS</a>. Y puedes firmar tu solicitud con esa identidad de servicio, IEM para la identidad de <a href="/tags/aws">AWS</a>, y luego enviar esa solicitud para que sea autorizada. Luego, la opción final es OpenID Connect, que te permite conectarte directamente a tu proveedor de identidad (IDP). Pero la que vamos a utilizar es el grupo de usuarios de Cognito, ya que ya lo hemos incluido. Y lo que vamos a hacer es separar las operaciones que se realizarán con la clave de API y las operaciones que se autorizarán mediante el token de acceso en el esquema. Y esto se hace con el concepto de directivas de esquema. Si miras rápidamente aquí, es bastante explicativo, pero puedes ver aquí que el tipo libro puede ser, en realidad no quiero centrarme en el tipo libro, quiero centrarme en las operaciones porque se siente más natural. Si revisas, por ejemplo, aquí las operaciones, para crear libros, actualizar libros y eliminar libros, el método de autorización que se utilizará o que se debe utilizar es el grupo de usuarios de Cognito. Esto significa que si proporcionas una clave de API, se te denegará automáticamente. Y si proporcionas un token de acceso válido de Cognito, entonces se te autorizará. Podemos probarlo de inmediato, después de configurarlo. Definitivamente podemos intentarlo, sí. En el lado de la consulta, ya lo hemos definido para que tengamos la clave de API como método predeterminado. Sin embargo, también puedes proporcionar los grupos de usuarios de Cognito si tu aplicación ya puede proporcionar estos tokens de acceso. Eso es todo. Este cambio requiere que cambiemos nuestro esquema porque actualmente no lo expresa.

¿Qué vamos a hacer? Antes de eso, debes agregar el modo de autorización Cognito aquí como un método adicional de autorización. ¿El orden no importa, verdad? Claro. Lo siento, tienes razón. Soy terrible siguiendo paso a paso. Tienes toda la razón. Veamos el esquema. Aún necesitamos... Esto no es suficiente porque necesitamos configurarlo para que AppSync sepa que debe usar un grupo de usuarios de Cognito específico. AppSync no adivina. Por lo tanto, necesitamos configurar estos modos de autorización adicionales. Y puedes ver aquí, para los modos de autorización que describí, vamos a seleccionar el grupo de usuarios de Cognito en nuestra región. La región que estamos usando para la masterclass. Puedes ver aquí que seleccionas un grupo de usuarios específico. No es aleatorio. Tal vez esta cosa del ID de cliente rechaza, puedes aplicar algún tipo de validación ya en el token de acceso, creo. No, esto es el ID de cliente. Para prevenir, digamos, abusos, como ataques DDoS, personas enviando IDs de cliente aleatorios allí. Oh, pensé que era... Vale. Cuando creaste el grupo de usuarios de Cognito, también creaste un cliente. Tal vez si vas a eso, si aún lo tienes abierto. Sí, aquí tienes la pestaña de integración de la aplicación de la masterclass. Entonces básicamente así es como lo vas a crear. Ahí está. El cliente de la aplicación de la masterclass. Exactamente. Aquí tienes un ID de cliente. Obviamente, para que una aplicación web se comunique con esto, requerirá un ID de cliente. Puedes crear... Creo que hay un límite de 25 en cuántos clientes puedes especificar para un grupo de usuarios. Pero básicamente, cualquier tipo de aplicación necesitaría eso. Nuevamente, nada específico de Cognito aquí. Si usas <a href="/tags/azure">Azure</a> AD u Okta o Ozero o cualquier otro, funcionará exactamente de la misma manera. Necesitarás el ID de cliente. En algunos casos, si tienes un tipo de cliente confidencial, también necesitarías un secreto. Pero para el propósito de hoy, solo tenemos un ID de cliente. Y esa expresión Rex limitaría a las personas que intentan IDs de cliente aleatorios contra tu API. Básicamente, se eliminarían antes de llegar a ella. Sí. Estoy filtrando anticipadamente. Exactamente. Ahora, sí. Ahora hemos configurado los grupos de usuarios de Cognito. Hemos... Para resumir, en esta sección, hemos creado nuestra API. Hemos creado dos modos de autorización. Uno de ellos, claves de API integradas en AppSync. El otro, Cognito. Hemos creado este grupo de usuarios de Cognito. Hemos registrado a nuestro usuario y hemos configurado qué operaciones deben ser autorizadas por Cognito y cuáles deben ser autorizadas mediante clave de API. Con esto, tenemos la base para comenzar a utilizar nuestra API, porque ahora tiene operaciones y es segura. Ahora, en teoría, ya podemos incluso hacer consultas a la API. Pero lo dejaré en tus manos porque tenemos esta sección de <a href="/tags/testing">testing</a> y <a href="/tags/debug">debugging</a>. Y solo quiero seguir el flujo de la masterclass para no confundir a la gente. Emanuel, creo que ahora puedes tomar el control, porque... Sí, claro. Veamos si puedo hacerlo bien. Vale. Espero... Deshazte de estas ventanas y demás. Espero que puedas ver mi pantalla. Tengo una pantalla un poco más grande que estoy compartiendo. Espero que aún sea visible para todos.

Miguel, tal vez puedas confirmar. ¿Se puede leer? Puedo confirmar. Todo se puede leer. Perfecto. Genial. Así que acabamos de tener el esquema que acabamos de crear. Tal vez me gustaría dedicar un poco de tiempo a describirlo con un poco más de detalle. Y luego, en realidad, me encantaría probar un par de consultas para validar lo que acabas de describir, que se puede usar la clave de API solo para lecturas. Y si quieres usar grupos de usuarios de Cognito, funciona tanto para lecturas como para escrituras. Y luego vamos a pasar a eso en tiempo real, que es muy, muy interesante y emocionante. Así que ahora un poco de ideas aquí sobre este esquema. Así que tenemos varios tipos, ¿verdad?, en los que ya hemos pasado algún tiempo describiendo. Tenemos el tipo base book. Y luego tenemos... Dejaré este book connection por un momento. Luego tenemos esta entrada, que se utiliza para mutaciones. Luego tenemos otro tipo para eliminaciones. Y luego tenemos un tipo para filtrado. Así que verás que <a href="/tags/graphql">GraphQL</a> es bastante capaz aquí. También dedicaremos un poco de tiempo a jugar con las consultas. Podrás ver que puedes hacer consultas muy avanzadas, como filtrado. Así que digamos que quieres un libro que tal vez tenga un ID de editor específico o que esté en un año de publicación entre 2005 y 2010. Así que puedes hacer todo tipo de consultas locas e interesantes sin necesidad de cambiar necesariamente la API, ¿verdad? Comparando nuevamente con el mundo de la API REST, necesitamos implementar diferentes parámetros de consulta y parámetros de ruta para diferentes cosas que puedas querer obtener. <a href="/tags/graphql">GraphQL</a> tiene esto integrado de forma nativa y no necesitas hacer nada en particular. Y verás que parte de esa magia también se hace a través de los resolvers. Aparte de estas cosas, también quiero aclarar esta parte con una conexión de libros. Como cualquier API inteligente debería hacer, tenemos el concepto de paginación, ¿verdad? No podemos obtener todos los libros que tal vez tengamos en nuestra tienda, que tal vez devuelva cientos de miles de libros. Así que probablemente querremos limitar la cantidad de libros que obtenemos en una solicitud. Y luego podemos ir página por página y obtener los siguientes 25 o los siguientes 50, dependiendo del tamaño de página. Así que para eso es esto. Y ahora verás, como mencioné, tenemos diferentes tipos de filtros. Estos NE y EQ, básicamente son abreviaturas de igual o menor que, mayor que, etcétera. Tenemos contained, para tipos de cadena, diferentes cosas diferentes. Y tal vez lo otro que es muy interesante, ¿verdad? Creo que lo cubrimos en la presentación, pero tal vez no miramos tanto el esquema es que tenemos un par de, digamos, tipos de alto nivel. Y luego tenemos mutaciones. Esas son cosas que cambiamos. Así que creamos, actualizamos y eliminamos, y luego tenemos consultas. Así que estas son lecturas, ¿verdad? Queremos obtener algo, queremos obtener un libro específico o queremos obtener la lista de libros y queremos obtener una lista filtrada de libros y diferentes otras cosas. Así que podemos crear todo eso. Y luego para la parte en tiempo real, lo cubriremos cuando lleguemos allí, tenemos la suscripción y lo dejaré para cuando lleguemos allí para mantenernos, digamos, emocionados por un rato más. Así que ahora lo que quería hacer es tal vez probar un par de consultas. Así que si vas a esta pestaña de consultas en el lado izquierdo, verás que tienes todo lo que se enumeró en el esquema aquí. Así que tienes las mutaciones, tenemos las consultas y tal vez deberíamos probar un par de mutaciones y luego un par de consultas para ver cómo funciona eso. De acuerdo. Así que si vamos aquí a la masterclass nuevamente, y si vas a probar tu API, deberías tener un par de mutaciones que podemos tomar para que podamos hacer una prueba y ver qué sucede. De acuerdo. Voy a copiar eso en mi cosa, y estoy usando la clave de API. Así que solo para que veas qué va a suceder. Así como lo describimos, ¿verdad?, vamos a obtener aquí no autorizado. ¿Por qué obtenemos el no autorizado aquí? Es porque no puedo mover esto. De acuerdo, ahora es porque aquí, en el esquema, en la mutación, para crear un libro, solo tenemos que necesitar los grupos de usuarios como una directiva. Así que no tenemos que, como tenemos en las consultas, la clave de API, ¿verdad? Si lo cambiaría y agregaría la clave de API, entonces también podría crear libros sin una clave de API. Entonces, para nosotros, para crear claves de API, necesitaremos cambiar este modo de autorización a grupos de usuarios de Conneto. Tendrás que hacer clic en iniciar sesión con el grupo de usuarios y seleccionar el cliente ID que creamos. Y aquí entra en juego el usuario que creamos para probar. Así que fue tester y creé una contraseña. En tu caso, deberás usar la contraseña predeterminada que se generó para ti por correo electrónico. Y una vez que hagas clic en iniciar sesión, aparecerá otro diálogo que te pedirá que crees una nueva contraseña. Yo ya lo hice mientras Miguel estaba presentando, así que no necesito hacerlo. Pero básicamente es algo por lo que debes pasar. Debería ser muy rápido. Y después de iniciar sesión, verás que ahora estoy conectado y podré crear ahora mi mutación, ¿verdad? Así que simplemente pude crear una mutación. Ahora quiero explicar un poco qué está pasando aquí. Así que creé una mutación, ¿verdad? Y pasé esta entrada, un ID, un ID del autor, año de publicación, título e ID del editor. Si recuerdas cuando creamos el modelo de datos aquí, algunos campos eran obligatorios, ¿verdad? Así que el ID, el título, el ID del autor y el ID del editor. Más tarde, cambiamos el ID para que ya no sea obligatorio. De lo contrario, DynamoDB simplemente creará un ID para ti. Pero todavía tenemos estos tres campos que son obligatorios. Todo lo demás es opcional, ¿verdad? Así que si miras nuevamente la solicitud, pasamos aquí solo cinco campos. Pero ¿qué sucede si quiero enviar ahora, digamos, más información? Así que digamos, alguna descripción que básicamente divida mi formato. Así que probablemente solo lo agregaría aquí.

Entonces puedo agregar una descripción a este libro, ¿de acuerdo? Y lo haré a propósito para que veas qué sucederá. Así que mi nuevo libro, algo simple. Así que simplemente actualizamos otro libro. Y verás que la respuesta no ha cambiado. La razón por la que aquí, dentro de esas llaves, especificamos lo que queremos obtener de esta solicitud, ¿verdad? Y no pasé la descripción. Así que simplemente creé el libro, pero no podemos decir si es diferente o no. Así que ahora, si agrego la descripción y lo ejecuto nuevamente, debería obtener mi nuevo libro, ¿verdad? Así que solo quería mostrarte estas dos cosas: que no tienes que pasar los campos que no son obligatorios y cuando los pasas, no necesariamente quieres recibirlos de vuelta. Así que tienes toda esta flexibilidad. Así que creemos tal vez un par de libros más a partir de estos ejemplos aquí, solo para poder jugar un poco más con algunas otras cosas. De acuerdo, genial. Así que ahora creamos otro libro. Ahora quiero probar un poco algunas consultas. Así que haremos la lista de libros. Intentemos ejecutar eso. Nuevamente, aquí, necesitaremos proporcionar qué cosas queremos obtener, ¿verdad? Por ahora, no tengo nada. Pero si solo quiero obtener el ID del autor y la descripción, puedo ejecutar esa consulta. Y verás, creé un par de libros. Y solo obtengo la descripción. Y algunos de ellos no tienen nada porque no los agregamos. Pero algunos ya se crearon con la descripción. Y si quiero tener más información, puedo agregar todo aquí y simplemente obtendré más información de la fuente de datos. El punto de esto es básicamente mostrar el poder de <a href="/tags/graphql">GraphQL</a>, el hecho de que puedes obtener tanta información o tan poca información según tu caso de uso. Así que digamos, si tienes, como verás en el <a href="/tags/frontend">frontend</a>, una lista de libros, solo mostrándolos como una lista de productos, tal vez solo quieras obtener un par de información, tal vez la imagen, el título del libro y tal vez cuándo se publicó. Y luego, una vez que hagas clic en ese libro, tal vez quieras obtener toda la descripción del producto, luego llamarás al mismo punto final. Pero solo estamos solicitando más información, ¿verdad? Entonces no tienes este problema de solicitar más datos de los que realmente necesitas, sino simplemente obtener los datos correctos que necesitas en esa página específica, ¿verdad? Entonces tus consultas se ejecutarán súper rápido y no correrás el riesgo de exponer demasiados datos que no necesitas. De acuerdo. Así que ejecutamos un par de consultas. Tal vez también quieras ver, esta es una lista de libros. También podemos ejecutar tal vez un libro específico por autor tal vez. Déjame ver si puedo obtener un ID de autor, uno, dos, tres aquí. Simplemente puedo ejecutar eso. Ups. Veamos, tal vez eliminaré esta parte. Y aquí, lo mismo, quiero obtener, digamos, el ID del editor y el ID del autor solo para verificar. Así que ahora simplemente obtengo todos los libros por índice de autor, todos los libros con el autor uno, dos, tres, y creo que había otro, siete, ocho, nueve, si no me equivoco. Sí. Así que también tenemos un libro con ese. Nuevamente, súper poderoso. Simplemente creando ese modelo de datos en el que pasamos, no sé, media hora haciendo, ahora tenemos todos estos filtros posibles y demás. Y genial. Ahora, tal vez queremos, veo que hay algo de actividad en el chat, pero en realidad no estoy seguro de qué es esto. Estoy seguro de que Miguel se está ocupando de eso. Si hay algo que no está claro, no dudes en preguntar. Tal vez ahora pasemos a este aspecto en tiempo real de la aplicación, ¿verdad? Hasta ahora hemos hecho estas consultas y mutaciones, ¿verdad? Esas son equivalentes a obtener publicaciones. No hicimos ningún tipo de actualización o eliminación, pero entiendes la idea. Ahora queremos pasar a otra área de, digamos, fortalezas de <a href="/tags/graphql">GraphQL</a>, ¿verdad? Mencionamos al principio que muchos de los casos de uso, cuando se trata de <a href="/tags/graphql">GraphQL</a>, son esencialmente suscripciones o actualizaciones en tiempo real. Y con razón, tuvimos, creo, un gran proyecto si sigues el fútbol con una gran liga de fútbol en Europa. Y esencialmente, el caso de uso allí era que tendrías una aplicación en tu teléfono y querrías recibir actualizaciones en vivo de lo que está sucediendo en el partido. Y piensas que, o tal vez solo estás interesado en quién marca y cosas así, pero en realidad esas actualizaciones serían mucho más interesantes. Así que, por ejemplo, para eventos importantes como penales o situaciones arriesgadas, donde hay, digamos, una anticipación que se acumula, recibirás todas estas actualizaciones en vivo. Y todo lo que puedo decirte es que en términos de rendimiento, en realidad logramos que la API fuera tan rápida que la aplicación era más rápida que lo que estaba sucediendo en la televisión. Si no sabes qué está sucediendo cuando ves la televisión, incluso si es un evento deportivo en vivo, no es esencialmente en vivo. Hay un poco de retraso. Dependiendo de lo que estés viendo, puede ser de 30 segundos a un minuto de retraso. Así que entre lo que está sucediendo físicamente en el estadio y lo que se transmite en la televisión, y con, digamos, lo que estábamos haciendo y la forma en que estábamos transmitiendo los datos, la aplicación era demasiado rápida. Informaba eventos que estaban sucediendo antes de tiempo a medida que sucedían en la televisión, solo para mostrarte cuán eficiente podría ser. Entonces, al final, tuvimos que hacer algún tipo de retraso artificial para que, digamos, la aplicación estuviera sincronizada con lo que estaba sucediendo en la transmisión en vivo. Pero la idea aquí es que esos casos de uso son para aplicaciones en tiempo real. Utiliza WebSockets como tecnología detrás de escena. Básicamente, puedes obtener un flujo de datos en tiempo real. Y esto funciona a escala. Entonces podrías tener, digamos, una aplicación con miles de usuarios suscritos, y todos ellos recibirían el evento al mismo tiempo. No hay muchos casos de uso que necesitarían este tipo de aplicaciones en tiempo real, pero también se puede usar para otras cosas. Digamos que estás creando, digamos, un trabajo de simulación o cualquier otro proceso largo en ejecución. La forma en que tradicionalmente podrías hacerlo en el mundo de REST sería que creas tu trabajo con un post en un recurso específico, y luego tendrías, digamos, un get en el mismo recurso para obtener el estado. Y tal vez lo hagas con una consulta cada, no sé, 10 segundos o 30 segundos, dependiendo de cuánto dure ese trabajo. Y cada vez, digamos, 10 segundos,

cada 10 segundos llamarías a ese recurso para obtener el estado. Bueno, no necesitarás hacer nada de eso con las suscripciones en AppSync, porque básicamente te suscribes a las actualizaciones de estado, ¿verdad? Y una vez que el estado haya cambiado, tu aplicación recibirá automáticamente una notificación. Así que tienes este mecanismo de suscripción superior agradable, y se maneja completamente sin problemas para ti. Así que no necesitas hacer nada excepto crear este hermoso esquema aquí que ya se ha descubierto, que ya hemos hecho en AppSync. Solo lo cubriré brevemente. Así que aquí tenemos un tipo diferente, ¿verdad? Antes teníamos consultas y mutaciones y otros tipos base. Y ahora tenemos un nuevo tipo, que llamamos suscripciones. Y básicamente, tenemos algunas aquí. Tenemos la suscripción on create book, la suscripción on update book y la suscripción on delete book. Hay una convención de nomenclatura aquí, como puedes ver. Es on evento. Y esos eventos son específicamente mutaciones, ¿verdad? Queremos escuchar eventos sobre un cambio específico en el objeto. Y aquí, porque solo tenemos creaciones, actualizaciones y eliminaciones, tenemos una suscripción para cada una. Y nuevamente, en cuanto a la sintaxis, ¿verdad? Estos son los objetos que puedes solicitar cuando escuchas esta suscripción, ¿verdad? Digamos que te suscribes y quieres ver cuando se actualiza un libro, puedes solicitar este tipo de campos. Y este es el esquema, ¿verdad? Esto te da control como servidor para decirle a los clientes qué es posible que soliciten. Y por supuesto, tú como cliente, puedes solicitar cualquiera de esas cosas, pero no puedes solicitar algo que el esquema no especifique. Creo que aquí está muy claro. Y ahora esta directiva aquí, <a href="/tags/aws">AWS</a> subscribe, básicamente dice, okay, ¿en qué está escuchando este evento? Y en nuestro caso, estará escuchando create book. De manera similar, se aplica a update book y delete book, ¿verdad? Y realmente lo probaremos y veremos cómo funciona. Probablemente veas aquí la explicación. En realidad, tomaremos esta suscripción on create book y la escucharemos, y veremos cómo funciona. Así que voy a ir a AppSync. Voy a copiar eso. Voy a ejecutarlo. Así que ahora ves que dice suscribirse a una mutación, ¿verdad? Y hay como un círculo de carga aquí, mostrando que se está cargando. Tal vez lo que podría haber hecho también es mostrarte la parte de la red. Haré una recarga y limpiaré todo aquí en el lado de la red, para que veamos qué hay

lo que realmente sucede si estás interesado en la capa de red. Veamos si puedo de alguna manera hacer esto un poco más pequeño para poder copiarlo. Tal vez no. De acuerdo. Lo haré y luego la red de nuevo. Muy bien. Veamos aquí. Y estamos buscando, en realidad no está aquí. ¿Verdad? Un segundo. Creo que está aquí. Correcto. Verás que esto es básicamente el WebSocket que está conectado. Verás un par de cosas interesantes aquí. Esto es básicamente solo el mantenimiento de la conexión. Habrá mensajes que lleguen de vez en cuando. De vez en cuando. Lo interesante será que una vez que cree una mutación en CreateBook, deberías ver que el mensaje llega. Por supuesto, la <a href="/tags/cli">console</a> también lo mostrará, pero solo quería mostrarlo en la red también. Así que voy a crear una nueva pestaña para las consultas y voy a crear un nuevo libro. Así que vamos aquí, <a href="/tags/testing">testing</a> tu API, y vamos a tomar esta mutación CreateBook3 y la vamos a poner aquí. Muy bien. Así que vamos a ejecutar esto. Ups. Vamos a ejecutar este. Oh, copié todo. Lo siento. Solo quería copiar el primero, el tercero. Por supuesto, estoy usando la clave de API, no está permitido. Así que nuevamente, necesito iniciar sesión con mi nombre de usuario, contraseña. De hecho, puedo escribirlo correctamente. Nuevamente. Muy bien. Así que creamos otro libro y en primer lugar, aquí en el lado derecho, hemos recibido los <a href="/tags/data">data</a>, ¿verdad? Así que hemos recibido la suscripción <a href="/tags/data">data</a> y verás que solo muestra el ID y el título. Y la razón de eso es porque, cuando nos suscribimos, solo pedimos el ID y el título. Por supuesto, podríamos pedir todas las cosas que tenemos en el esquema, que es el ID del editor, el título, el ID del autor, todos los demás <a href="/tags/data">data</a> que se encuentra en el esquema. Pero en nuestro caso, solo pedimos el ID y el título. Aunque en la mutación enviamos mucha más información. ¿Verdad? Así que te permite flexibilidad como cliente para pedir cualquier <a href="/tags/data">data</a> que desees. Y espero que aquí también veamos eso en el flujo WebSocket, recibimos la misma carga que se muestra aquí en el lado derecho. Así es como lo verás en el front-end, básicamente. Recibes, mientras escuchas el flujo, mientras te suscribes al flujo, recibes un flujo continuo de <a href="/tags/data">data</a> y tendrás que poder <a href="/tags/react-components">react</a> a ese evento. Afortunadamente, si tienes un front-end <a href="/tags/frameworks">framework</a>, como <a href="/tags/react-components">React</a> o <a href="/tags/angular">Angular</a>, eso es súper, súper fácil de hacer. Y hay funcionalidad incorporada para eso. Así que podrás recibir la información fácilmente y actualizar tu <a href="/tags/user-interfaces">UI</a> sin problemas. ¿Verdad? Por lo tanto, no es necesario que el <a href="/tags/user-interfaces">UI</a> se actualice ni que cambie las URL ni nada por el estilo. ¿Verdad? La actualización puede cambiar automáticamente sin ninguna interacción del usuario o sin ningún tipo de llamadas adicionales a la red que pueden ser costosas. Es un flujo continuo de <a href="/tags/data">data</a>. Genial. Esa sería la parte de las suscripciones en tiempo real. Obviamente, podemos probar lo mismo con las suscripciones on update book, on delete book, pero creo que espero que hayas entendido la idea principal. Así que no voy a probar la suscripción de eliminar libro o la suscripción de actualizar libro. Cualquier pregunta relacionada con las suscripciones que tal vez no haya respondido aún. Si no, intentaré avanzar. Tal vez una cosa importante que señalar, Emmanuel, es que este tipo de suscripción, puedes usarlo como una actualización en tiempo real, pero no puedes considerarlo como un historial de notificaciones duradero. Así que si hay suscriptores activos en ese momento que están suscritos a un tema específico o a una mutación específica, recibirán esta información. Pero si llegas tarde, no recibirás estos mensajes. Correcto. No recibirás este historial. Sí, por supuesto. Solo recibirás actualizaciones más recientes. Correcto. Hay formas de lidiar con ello, pero no es parte del tema, pero eso es correcto. Nuevamente, depende mucho de tu caso de uso. El caso de uso que mencioné con los deportes o el caso de uso que acabo de mencionar, digamos, tener un trabajo que dura mucho y solo quieres recibir actualizaciones sobre eso, creo que no sufren de esto. Pero podría haber

 potencialmente como juegos, por ejemplo. Si abandonas la sesión y te unes más tarde, necesitarás obtener todas esas cosas acumuladas. Y también hay esta funcionalidad adicional relacionada con la interacción sin conexión, pero nuevamente, no la estamos cubriendo en este momento. La pregunta fue, ¿puede enviar eventos diferentes a diferentes usuarios en la misma suscripción? No. Correcto. Todos los suscriptores recibirán la misma carga útil exacta como acabo de demostrar. Podemos crear tres pestañas con diferentes suscriptores, recibirán la misma carga útil exacta. Y luego la otra pregunta es, ¿es posible enviar eventos sin una mutación adicional? Por ejemplo, ¿directamente desde EventBridge?

No. Así que supongo que es muy bueno que conozcas EventBridge, pero no. Correcto. Verás cuando creemos las suscripciones aquí, básicamente tenemos esta directiva que dice, ¿a qué estoy escuchando? ¿Qué tipo de evento? Y no puedes escuchar eventos que no provengan de mutaciones en AppSync. No puedes escuchar eventos que provengan de EventBridge o un flujo de datos de DynamoDB o Kinesis, si estás familiarizado con eso, solo palabras de mutaciones. Pero podrías crear, si quieres, un flujo de trabajo compuesto. Digamos que si tienes un evento proveniente de EventBridge, necesitas tener un controlador para ese evento. Y luego ese evento puede desencadenar una mutación en AppSync y crear una especie de tubería integrada agradable. Pero no, por defecto, no es posible. Sería genial, estoy de acuerdo. Correcto. Porque entonces con EventBridge, puedes conectar esa pieza en tantos lugares, y podrías tener un flujo gemelo. Pero no, solo funciona suscribiéndose a mutaciones. Así que cambios en los <a href="/tags/data">data</a>, ¿verdad? Tienes una API, quieres cambios en ese <a href="/tags/data">data</a>, esos eventos provienen de otro lugar. Sí, la alternativa, ¿verdad?, con EventBridge es que puedes conectar EventBridge a SNS y también tienes un mecanismo de publicación-suscripción allí con el que puedes trabajar. Pero esto es específico de la API de <a href="/tags/graphql">GraphQL</a>.

Sí. Genial. Ahora tal vez podamos dedicar unos minutos a los resolutores de AppSync. Ejecutamos todas estas consultas y mutaciones y suscripciones, ¿verdad?, pero realmente no hemos visto lo que está sucediendo detrás de escena, ¿verdad? Así que tal vez echemos un vistazo, porque interactuamos con la API, pero nunca realmente vimos la capa de almacenamiento de datos, ¿verdad? Así que si volvemos ahora a DynamoDB, que es nuestra capa de almacenamiento de datos persistente en este momento, verás que tenemos nuestra tabla de libros y ahora deberíamos poder ver todas las cosas que hemos creado, ¿verdad? Así que verás que tenemos estos IDs con ID de autor, con descripción, publicación, año, ID de editor, etc., título y muchas cosas más. ¿Cómo se está poblado esto en realidad y cómo <a href="/tags/graphql">GraphQL</a> o AppSync sabe cómo recuperar esto, ¿verdad?, y esto funciona con los resolutores. Verás que la forma en que hemos creado los resolutores hasta ahora es con los resolutores de AppSync, los resolutores de <a href="/tags/javascript">JavaScript</a> que están integrados en el servicio directamente. Así que vamos a echar un vistazo a uno de ellos. Digamos que queremos ver un resolutor de consulta, tal vez para estos libros podemos hacer eso. Así que hicimos clic en ese resolutor, tal vez hice clic demasiado rápido, así que volvamos atrás de nuevo. Así que en el lado del resolutor, para la consulta, tenemos este resolutor aquí, tabla de libros, y verás que se abre un poco así, y hay algún código <a href="/tags/javascript">JavaScript</a> aquí que tal vez te preguntes, ¿qué es esto? Básicamente, lo que hace este código de resolutor es hacer una consulta contra la fuente de datos. Tiene esta función llamada solicitud, que es esencialmente la parte que va a la fuente de datos, y luego tenemos una función de respuesta que esencialmente responde de vuelta al solicitante. Ahora, ¿por qué esto puede ser súper interesante y súper poderoso? Bueno, puedes personalizar lo que se envía a la fuente de datos, en nuestro caso DynamoDB, y lo que se devuelve al cliente. En términos más simples, digamos que estás haciendo una solicitud a DynamoDB para devolver una lista de libros, ¿de acuerdo? Muy bien, podemos dejar esta solicitud muy simple. Pero en la respuesta, una vez que obtenemos los resultados de DynamoDB, podemos hacer, por ejemplo, transformaciones simples. ¿Qué podría ser eso? Digamos que podemos tener un precio y tal vez en DynamoDB tenemos un precio con 10 dígitos, lo que podemos hacer aquí es redondear ese precio con solo dos dígitos. ¿O queremos cambiar el nombre de un campo o hacer algunas agregaciones simples, como, digamos, quieres obtener, digamos, cuántos libros de un género específico tienes aquí? Así que puedes hacer todos estos cálculos simples aquí, y te di el ejemplo para la respuesta porque es un poco más fácil de entender. Puedes hacer cosas similares en la solicitud. Como ejemplo, digamos que hay una solicitud para ir a DynamoDB, pero quieres obtener esas respuestas, digamos, las respuestas, cuando haces la solicitud a DynamoDB, ordenadas por un campo específico. Así que, digamos, quieres obtener todos estos libros de este autor, listados por precio en orden descendente, ¿verdad? Obviamente, también podrías hacer eso en la respuesta, una vez que llegues a la respuesta de la base de datos en sí, pero es más eficiente hacerlo en la capa de la base de datos misma. Así que, ese es el poder de usar esos resolutores de <a href="/tags/javascript">JavaScript</a>. Obviamente, es bastante limitado en términos de cosas que puedes hacer, así que no puedes, por ejemplo, devolver 100,000 elementos de una base de datos y esperar poder hacer cálculos complejos y cosas por el estilo. Eso no será posible, pero para cosas simples, funciona bastante bien. Y aquí, en el lado derecho, tenemos muchos ejemplos de consultas y operaciones por lotes y demás. Así que, digamos, si quieres obtener los 10 mejores elementos o los 100 mejores elementos, y ese es, por ejemplo, el límite para las operaciones por lotes que tienen una propiedad específica. Así que, digamos, si quiero tener los primeros 100 libros, ¿verdad? Funciona con la paginación. Los primeros 100 libros que provienen de este autor o que tienen, digamos, un precio mayor o menor a 100 euros. O que todavía son 100 euros por un libro. Eso es bastante. Pero entiendes lo que estoy tratando de decir, ¿verdad? Puedes hacer todas estas cosas complejas en los resolutores. Y así es como funciona detrás de escena. Y esos resolutores son resolutores nativos. También hay otro tipo de resolutores. No sé si vale la pena entrar en ese nivel de detalle. Miguel ya explicó que puedes tener un resolutor de <a href="/tags/lambda">Lambda</a>. Eso es lo más poderoso. Porque en un <a href="/tags/lambda">Lambda</a>, puedes tener tu propio tiempo de ejecución personalizado. Así que puedes programar en Python si no te gusta <a href="/tags/javascript">JavaScript</a>, por ejemplo. O si tienes, digamos, personas en el equipo que no conocen <a href="/tags/javascript">JavaScript</a> y quieren programar en Python, puedes usar un resolutor de <a href="/tags/lambda">Lambda</a> y programar en Python. Funciona de manera muy similar. Tienes una función que hace una solicitud y una función que devuelve la respuesta. Pero puedes hacer muchas cosas más poderosas porque <a href="/tags/lambda">Lambda</a> en sí es un servicio. Tiene mucha más potencia de cómputo que esta ejecución de AppSync. Así que, esta ejecución de AppSync que también ves aquí en la parte inferior izquierda, no lo sé de memoria, pero son milisegundos. No puedes ejecutarlo durante medio minuto o algo así. Así que tiene que ser bastante pequeño. La otra parte importante, ¿verdad?, y tal vez no discutimos tanto eso, es este resolutor, funciona contra la fuente de datos. En nuestro caso, la tabla de DynamoDB. Y tal vez sea un buen momento para discutir qué otro tipo de fuentes de datos puedes usar en AppSync. Así que, si vuelvo a la estructura, también verás que puedo adjuntar resolutores a cualquier tipo de campo. Entonces, ¿en qué puede resultar esto, o qué tipo de funcionalidad adicional puedes tener, es a lo que me refería antes con los tipos compuestos? Así que, digamos que tienes este tipo libro, y luego en lugar del ID de autor, tendrías otro tipo llamado autor, podrías adjuntar un resolutor a ese campo específico y puedes obtener, por ejemplo, la información relacionada con los autores desde otra base de datos u otra fuente de datos. Y por eso quería discutir un poco cómo funcionaría eso. Así que, si quisieras adjuntar otro resolutor a un campo específico, puedes elegir entre un resolutor unitario y un resolutor de canalización. También hablaremos sobre los resolutores de canalización en un momento. Y el tiempo de ejecución que ya discutimos, el VTL, es un lenguaje de Apache, honestamente es terrible trabajar con él. La razón es que es súper verboso y difícil de leer. Y probablemente quieras usar el tiempo de ejecución de <a href="/tags/javascript">JavaScript</a>. Y luego tienes un par de fuentes de datos. Y aquí, tienes fuentes de datos nativas para AppSync. Y también puedes tener fuentes de datos personalizadas. Entonces, las fuentes de datos nativas para AppSync son DynamoDB, OpenSearch, funciones <a href="/tags/lambda">Lambda</a>, puntos finales HTTP, EventBridge y bases de datos relacionales. Eso significa que no necesitas escribir ningún tipo de código para integrarte con esto. Simplemente nos integramos con DynamoDB. Viste que el código se te proporciona automáticamente por AppSync. Lo mismo ocurre con OpenSearch, funciones <a href="/tags/lambda">Lambda</a>, puntos finales HTTP, y así sucesivamente. Con puntos finales HTTP, ya tienes la posibilidad de combinar

AppSync permite la integración con otras APIs. Por ejemplo, podrías combinar una API de <a href="/tags/graphql">GraphQL</a> con una REST. Así que, digamos, que la información sobre los autores podría provenir de una API REST que es gestionada por otro equipo, por ejemplo. O puedes tener una API de precios que solo devuelve precios de libros, y quieres resolver esa información desde otra API que es gestionada por otra persona. Eso se podría hacer fácilmente con puntos finales HTTP. Y, por supuesto, si quieres realmente personalizar, una de estas cosas, y tenemos con nuestros clientes, siempre tienes la opción de una función <a href="/tags/lambda">Lambda</a>. Así que, con una función <a href="/tags/lambda">Lambda</a>, puedes solicitar datos literalmente de cualquier fuente de datos que puedas imaginar. Digamos, desde un almacenamiento local, desde una base de datos local, desde S3, desde cualquier cosa que puedas imaginar. Así que tienes todas estas posibilidades. Esencialmente, no estás limitado a nada. La ventaja es que si utilizas alguno de esos servicios de <a href="/tags/aws">AWS</a> que se enumeran aquí, tienes integración nativa y no necesitas programar nada con <a href="/tags/lambda">Lambda</a>. Tienes total flexibilidad, pero debes programar, lo cual es genial, creo.

A todos nos encanta <a href="/tags/code">code</a>. Pero a veces también queremos ser más productivos. Y volviendo a esto, también quiero hablar un poco sobre los pipeline resolvers. Como su nombre sugiere, un pipeline resolver es simplemente una cadena de resolvers. Entonces, básicamente, digamos que obtendrás, volvamos al esquema y busquemos un ejemplo. Y el ejemplo de los libros funciona bien aquí. Digamos que si tuviera estos libros. Y, digamos que el primer paso de este pipeline resolver es obtener todos los libros que se publicaron en 2024. ¿De acuerdo? Eso sería, digamos, el primer paso. En un segundo paso de este pipeline resolver, podría ser que consultemos otra API para determinar qué libros de este subconjunto que ya se publicaron en 2024 son de una ciudad específica o se pueden comprar en un minorista específico. ¿Verdad? Lo cual puede ser una API totalmente diferente. También puede ser una API externa. ¿Verdad? Entonces, si piensas en construir una solución de <a href="/tags/e-commerce">e-commerce</a> sobre esto, puede ser algo totalmente diferente. Y luego, al final, el usuario que hizo la consulta inicial obtendría toda esta información agrupada. Así que, obtiene todos los libros que se publicaron en 2024 y dice, okay, estos libros se pueden encontrar en Nueva York, en estos lugares, tal vez con direcciones también, con horarios de apertura tal vez, ¿verdad? Así que puedes enriquecer los datos bastante implementando todos estos pipeline resolvers. Ahora, nuevamente, en el resto del mundo, también puedes hacer eso. Pero eso requeriría en el lado del cliente muchas más llamadas. Entonces, primero, obtienen la lista de libros y para cada libro, realizan las otras llamadas a la API. Entonces, básicamente, trasladan todo ese trabajo pesado al lado del servidor en lugar de hacerlo en el lado del cliente, lo cual siempre es una ventaja. ¿Verdad? Los clientes siempre deberían ser, o idealmente deberían ser, clientes livianos. Sin tener que realizar ningún tipo de cálculo pesado y, por supuesto, cada vez que se realizan muchas solicitudes en el <a href="/tags/frontend">frontend</a>, se pierde tiempo y la experiencia del cliente puede no ser tan buena. Así que, creo que eso es un poco sobre el resolver. Todo eso, por supuesto, se explica aquí y hay muchos más ejemplos en términos de lo que puedes hacer con condiciones dentro de esos resolvers. Pero creo que cubrí bastante de lo que quería decir. Y la razón por la que tal vez no quería seguir hablando tanto de esto es porque también quiero construir la aplicación y quiero ver cómo se ve y probarlo contigo. Así que, me gustaría pasar ahora a esta parte de integrar nuestra API. Hasta ahora, hemos construido una API. Y ahora, nos gustaría conectar esta API con el <a href="/tags/frontend">frontend</a>. Para que veamos cómo esa aplicación se conecta a Konecto para autenticar al usuario y luego cómo obtiene los datos de AppSync. Por esa razón, utilizaremos un servicio llamado Amplify. No necesitas saber mucho al respecto, es simplemente una forma de alojar nuestro <a href="/tags/frontend">frontend</a>. Y para implementar y alojar ese <a href="/tags/frontend">frontend</a>, utilizaremos un ID en la nube llamado Cloud9. Así que, puedes hacer clic en ese enlace que te redirigirá directamente aquí. Y creo que ya debería tener un entorno, pero necesito cambiar las regiones. Así que, yendo a Irlanda, ya debería tener un entorno. Vamos a ver, necesito mover esto de algún lugar. De acuerdo. Así que puedo iniciar este entorno, puede que tarde unos minutos en inicializarse. Y básicamente, lo que haremos desde este entorno, verás que tenemos, tal vez pueda mostrarte ya, tenemos básicamente un repositorio en CodeCommit. Puedes pensar en esto como un repositorio Git, nada demasiado complicado aquí. Tendremos un repositorio <a href="/tags/frontend">frontend</a> y un repositorio <a href="/tags/backend">backend</a>. Y lo que haremos desde Cloud9 es implementar este repositorio <a href="/tags/frontend">frontend</a> en Amplify y luego podremos acceder a la aplicación y tal vez hacer algunos cambios de código para demostrar cómo se conecta a la API. Así que, aquí está el entorno de Cloud9. Ya está inicializado. Verás que tenemos los repositorios <a href="/tags/backend">backend</a> y <a href="/tags/frontend">frontend</a>. Así que, simplemente iremos a ese repositorio específico. Ejecutaremos <a href="/tags/npm">NPM</a> install, creo que era dash dash y no log level. No importa. Hará la instalación de <a href="/tags/npm">NPM</a>, instalando todos los módulos necesarios para el <a href="/tags/frontend">frontend</a>. Y después de eso, ejecutaremos estos comandos. Y lo que hará este comando, es básicamente conectar el <a href="/tags/frontend">frontend</a> con el grupo de usuarios de Cognito que acabamos de crear antes. Es solo una configuración en el lado del <a href="/tags/frontend">frontend</a>. Una vez que ejecutemos estos comandos, te mostraré exactamente cómo se ve. Pero solo estamos esperando a que termine la instalación de <a href="/tags/npm">NPM</a>. Espero que todos estén aquí y puedan inicializar Cloud9 y seguir adelante. No suelo trabajar mucho con Cloud9. Pero es realmente útil si quieres ejecutar cosas directamente en la nube sin necesidad de tener nada instalado en tu computadora. Y por ejemplo, podría conectarme a este Cloud9 desde mi computadora de trabajo, pero también desde mi computadora personal desde cualquier lugar del mundo. Es bastante poderoso de esa manera. Y tengo acceso a los repositorios. Obviamente, si no estás en línea, es decir, no tienes conexión a Internet, eso podría ser bastante difícil. Pero hay cosas interesantes que puedes hacer con él. Así que, estamos esperando que se instale. Mientras se carga eso, otra cosa sobre Cloud9 es que puedes conectarlo al explorador remoto de VS <a href="/tags/code">Code</a>. Entonces, puedes <a href="/tags/code">code</a> desde tu IDE de VS <a href="/tags/code">Code</a> con tus complementos. Pero en realidad, es solo una conexión SSH a Cloud9. Es algo que vemos que algunos de nuestros clientes utilizan porque necesitan este entorno estable o un entorno similar para todos. Exactamente. Seguro, es un problema de empresa donde quieren que todos tengan la misma configuración exacta. A veces, vemos que las personas usan diferentes IDE localmente, ¿verdad? Y eso podría generar problemas de configuración y crear problemas de estilo cuando se trata de formato y demás. Entonces, de esta manera, pueden proporcionar este entorno de manera uniforme para todos y tener

una experiencia unificada sin importar lo que estén usando localmente. Por ejemplo, yo prefiero usar PyCharm. Pero Python funciona. Sí, sí. Creo que con IDEs inteligentes, la mayoría de los IDEs inteligentes también funcionan. Es un poco más trabajo. Sí, por supuesto. Sí. Es un estándar SSH al final del día. Entonces, prácticamente cualquier cosa que pueda conectarse a eso, puedes hacerlo incluso en un juego o lo que sea. Vale. Esto está tardando un poco, pero creo que casi está listo. Bien. Ahora ha terminado. Vamos a ejecutar este GenerateConfig. Detrás de este GenerateConfig, por qué era importante nombrar el grupo de usuarios exactamente como está en el <a href="/tags/workshop">workshop</a> es porque este archivo por lotes busca ese grupo de usuarios con el nombre del <a href="/tags/workshop">workshop</a> y genera esta configuración. Y veamos la configuración que acabamos de generar. Así que, se refiere a estos. Obviamente, también podríamos completar esto manualmente, ¿verdad? Este es el punto final de <a href="/tags/graphql">GraphQL</a>, la clave de la API, la autenticación y el grupo de usuarios, etc. Obviamente, puedes obtener toda esa información, por ejemplo, desde AppSync. Ese es un punto importante aquí. Entonces, este es el punto final de <a href="/tags/graphql">GraphQL</a> que hemos configurado aquí. Importante, ¿verdad? Entonces, para ti, si quieres acceder a tu API, este es el único punto final. No es como en REST donde tienes muchos recursos y tienes verbos HTTP. No. En <a href="/tags/graphql">GraphQL</a>, tienes un solo verbo HTTP, por lo que cada consulta, mutación o suscripción es como un post, y luego tienes el punto final de WebSocket, que es exactamente este. Eso es todo, sí. Y básicamente con este lote, acabamos de generar esta configuración, y ahora vamos a hacer commit de esos cambios y los vamos a enviar al repositorio Git. En un entorno normal, no harías push a la rama principal, pero aquí estamos perdonados. Estamos en un <a href="/tags/workshop">workshop</a>. Y ahora el último paso que queremos hacer es simplemente implementar este repositorio en Amplify para que podamos acceder a la hermosa aplicación que acabamos de crear. Entonces, aquí voy a ir a Amplify. Vamos a hacer clic en crear y comenzar. Vamos a alojar nuestra aplicación web. No queremos construirla. Ya la tenemos. Vamos a elegir la fuente que se llama commit. Admite otros repositorios Git, como puedes ver aquí. Elegiremos el repositorio <a href="/tags/frontend">frontend</a>, la rama principal. Y vamos a dejar todo como predeterminado. Y siguiente, y guardar y implementar. Y esto nos llevará, creo, un par de minutos para aprovisionar, construir y luego implementar. Una vez que esté disponible, tendremos este enlace y abriremos la aplicación para ver cómo se ve. Esta es una aplicación simple de <a href="/tags/react-components">React</a>, pero está disponible a través del <a href="/tags/workshop">workshop</a>. Por razones de tiempo, no creamos algo desde cero. Pero haremos algunos cambios para que veas cómo funciona y lo simple que es conectar con la API. Mientras eso se está construyendo e implementando, hablaré un poco sobre la aplicación en sí. Una vez que abramos la página, podemos crear una cuenta nueva o puedes usar la cuenta que ya creamos, como prefieras. Probablemente usemos la cuenta que ya creamos para ahorrar tiempo. Pero tienes una función de registro, y la forma en que funciona es que está conectada al grupo de usuarios del comité que acabamos de crear. Un flujo similar funcionaría para cualquier otro proveedor de identidad. Y una vez que eso esté hecho, conectaremos la aplicación a la API para obtener todos los libros. ¿De acuerdo? Así que solo haremos la parte de lectura. No quiero perder mucho tiempo. No nos queda mucho tiempo para hacer todas las actualizaciones en tiempo real y demás. Pero al menos esa es la parte de los libros que me gustaría ver contigo. Así que esperemos a que termine esta parte. Y luego lo juntamos. Genial. Ahora tenemos nuestra aplicación. Como mencioné, podemos iniciar sesión con el usuario que creamos antes. O podemos crear una cuenta nueva o, por razones de tiempo, usaré el usuario que ya creé antes. Ahora ves que ya he iniciado sesión. Pero ahora hago clic en libros, y no sucede nada. ¿De acuerdo? Entonces, nuestro <a href="/tags/frontend">frontend</a> no está conectado a nada. Entonces, lo que haremos en los próximos cinco minutos, tal vez, es conectar el <a href="/tags/frontend">frontend</a> con la API. Y veremos todos los libros que tenemos. Así que hagámoslo rápido. Vamos a la sección de integración de tu API, usamos la parte de la API. Vamos a omitir esto,

Utilizaremos la API de creación de libros por ahora. Y queremos utilizar la API de listar libros, ¿de acuerdo? Entonces, dice que en el IDE <a href="/tags/cloud">Cloud</a> 9, queremos abrir este archivo específico, en este directorio en particular, y realizar algunos cambios. ¿De acuerdo? Entonces, los cambios son que esta es una aplicación de <a href="/tags/react-components">React</a>. Si no estás familiarizado, puedes ir directamente a la parte de la solución. Y copiaré esto y explicaré cómo funciona esto en realidad. Así que vamos aquí, en <a href="/tags/cloud">Cloud</a> 9, en el repositorio del <a href="/tags/frontend">frontend</a>, en components, en books. Y aquí, debería haber un comentario que dice, en la línea 47, estos libros, y hay un useEffect. ¿Verdad? Entonces, lo que queremos hacer es llamar a la API y obtener todos los libros que ya hemos creado. Tenemos una función aquí, una función de <a href="/tags/javascript">JavaScript</a> que realiza una llamada a la API de <a href="/tags/graphql">GraphQL</a> para consultar la lista de libros. ¿Verdad? Esto proviene del propio esquema. Configuramos un par de variables. Entonces, por ejemplo, esto probablemente es demasiado alto. No queremos listar todos los libros que mencioné. Probablemente hagamos la paginación que mencioné. Entonces, podemos obtener, digamos, solo los primeros 100 libros o lo que sea. Y luego, con el token siguiente, técnicamente podríamos iterar para obtener los siguientes 100 libros, y así sucesivamente. Y aquí, tenemos esencialmente un manejo de errores, y eso será muy sencillo. Y lo que haremos aquí, haremos commit de nuestros cambios y los enviaremos, y luego desplegaremos una vez más. Por supuesto, necesitamos guardar el archivo. Estoy usando una Mac. Estoy haciendo un Command S aquí. Pero en caso de que tengas Windows, es posible que necesites hacer un Control S, o ir a archivo y luego hacer clic en guardar. Continuamos desde aquí y luego guardamos. Así que hemos hecho commit de nuestros cambios. Ahora, podemos hacer un push. Y la parte hermosa es que ahora Amplify, una vez más, construirá esto y lo implementará. Y deberíamos ver los cambios en nuestro <a href="/tags/frontend">frontend</a> muy pronto. Así que demos un minuto para eso. Ahora, tal vez mientras esto se está implementando, un poco de información. Aquí hicimos todo manualmente, pero en un escenario empresarial, esencialmente hay herramientas. Por ejemplo, CodeGen puede generar, por ejemplo, el esquema para ti en el <a href="/tags/frontend">frontend</a> basado en el punto final de <a href="/tags/graphql">GraphQL</a> que acabas de tener. Entonces, eso puede ser bastante poderoso, ¿verdad? Si necesitas crear clases, interfaces directamente en el <a href="/tags/frontend">frontend</a> para manejar los objetos, simplemente puedes darle esta herramienta, el punto final de <a href="/tags/graphql">GraphQL</a>. Descargará el esquema, ¿verdad? Y generará todas estas clases e interfaces para que ganes bastante velocidad en lugar de crear todo manualmente. Obviamente, en nuestro caso, no hicimos nada de eso. Pero nuevamente, es porque estamos haciendo una prueba de concepto o prototipado rápido. En un escenario empresarial, tendrías que hacer todo eso. Sí. Y obtienes archivos de definición de <a href="/tags/typescript-libraries">TypeScript</a>. Así que obtienes el enlace y el resaltado del IDE de inmediato. Eso es realmente poderoso. Exactamente. Aquí ves, por ejemplo, hay un ejemplo donde tienen un esquema. Nuevamente, esto se puede descargar en tiempo de ejecución. Genera todas las interfaces y todo el código asociado con él y todos los tipos que se requieren en el <a href="/tags/frontend">frontend</a>. Entonces, así es como lo harías en un escenario empresarial. Lo que hicimos allí es solo algo que queremos ver cómo funciona la aplicación. Solo quiero darte también esa perspectiva. Tal vez otra cosa, Dimon. Perdón por interrumpir. Pero estás viendo Amplify aquí. Usamos Amplify como una biblioteca aquí, pero en realidad no necesitas usar Amplify. Por supuesto. Puedes simplemente conectarte a AppSync con cualquier cliente de <a href="/tags/graphql">GraphQL</a>. En teoría, incluso podrías... Hemos visto a algunos clientes que usan el cliente <a href="/tags/apollo">Apollo</a> en su aplicación <a href="/tags/frontend">frontend</a> para conectarse a AppSync porque es una implementación compatible de <a href="/tags/graphql">GraphQL</a>. Exactamente. Ahora, ves que después de que acabamos de insertar nuestra consulta a la API, obtenemos esta lista de libros. Tal vez no sea la mejor. Aquí, en este icono de configuración, tienes la opción de generar libros. Crearemos un par de ellos para ver cómo se llena esto realmente. Tal vez después de 5, 10 segundos, detendremos y actualizaremos la página para que veas cuántos libros se crearon en realidad. De acuerdo. Tal vez eso es suficiente. Creamos 100 libros. Eso es suficiente. Ahora, tenemos todos estos datos que se publican aquí, así que eso es bastante agradable. Y también tenemos la paginación implementada, por lo que podemos seguir avanzando según sea necesario. Ahora, obviamente, puedes complicar todo esto. Creo que en el siguiente paso del masterclass, podremos hacer actualizaciones en tiempo real. Por ejemplo, podemos... Por supuesto, si

Ya hemos cubierto la creación. Podríamos crear un libro llamado la API, y luego el <a href="/tags/frontend">frontend</a> no necesitará llamar nuevamente a la API para obtener todos los libros. Simplemente se suscribirá a esta mutación de libro y el <a href="/tags/frontend">frontend</a> se actualizará en segundo plano. Esto es bastante poderoso. Y las actualizaciones de temas también se pueden propagar a todos los usuarios. Entonces, si no... Todos los demás usuarios ya están aquí. Tal vez hagan una búsqueda. Bueno, esta búsqueda ahora también incluirá el libro que alguien más ha creado. Y sí, este es un ejemplo muy simple, pero piensa en el comercio electrónico, por ejemplo. Las personas agregan nuevos productos a tu comercio electrónico todos los días o cada minuto o lo que sea. Estás obteniendo esas actualizaciones sin problemas. Eso es bastante poderoso. Y mirando el tiempo, para ser honesto, creo que aquí es donde me gustaría detenerme. Obviamente, puedes continuar con la parte de mutación tal como se describe en el masterclass. Y luego, también hacer la suscripción. Así verás cómo funciona de principio a fin. Hay un aspecto de monitoreo y observabilidad que me gustaría cubrir rápidamente. Entonces, obviamente, te gustaría saber qué está sucediendo en la API en caso de que quieras depurar o en caso de que haya errores. Esto se hace muy fácilmente dentro de AppSync porque tienes estos servicios de <a href="/tags/aws">AWS</a> integrados. Simplemente puedes marcar una casilla en la configuración y luego tendrás el registro habilitado y puedes depurar todo eso usando CloudWatch. Y, por supuesto, si quieres ir más avanzado, también tienes X-ray. Entonces, puedes rastrear lo que está sucediendo desde el momento en que tocas sincronizar hasta la fuente de datos real en DynamoDB, y también puedes realizar análisis de rendimiento o lo que sea. Tal vez para aquellos que no están familiarizados con CloudWatch. Sí, claro. CloudWatch es simplemente una solución que recopila información y es un servicio complejo en el sentido de que recopila tanto registros que son útiles para depurar cosas, pero también métricas. Cosas como, no sé, depende del servicio que recopilemos métricas, pero para las API, por ejemplo, podrían ser cuántas solicitudes 200 o 200, el número de solicitudes, cuántas 500, cuántas 400, cuántas solicitudes no autorizadas. También puedes ver, por ejemplo, el tiempo de respuesta y muchas otras cosas. Y dependiendo si tienes, por ejemplo, una base de datos, también verás el uso de memoria, la CPU y todas estas otras cosas. Y CloudWatch tiene muchas más características que eso. No quiero entrar en detalles, pero es como el lugar al que acudir para monitorear y registrar cosas. Y está estrechamente integrado con todos los demás servicios de <a href="/tags/aws">AWS</a>. Entonces, es el lugar al que acudir para ese tipo de cosas. Y tal vez lo que sería interesante también si quieres explorar, como mencioné, este laboratorio estará abierto durante dos días. También podrías intentar integrar AppSync, como mencioné, con otras fuentes de datos como API REST o incluso hacer las API combinadas. Entonces, esto es esencialmente lo que dije. Puedes combinar diferentes API provenientes de diferentes equipos en un escenario empresarial en una sola y realizar consultas realmente complejas. Pero creo que en términos de actividades prácticas, me gustaría detenerme aquí y tal vez pasar un poco a la presentación y cerrar porque no hay mucho más tiempo disponible.

Pero aún así, creo que te has familiarizado con los conceptos básicos de <a href="/tags/graphql">GraphQL</a>. El hecho de que puedas hacer consultas, mutaciones y suscripciones. Y cuál es el caso de uso para todo y cómo puedes hacer los conceptos básicos de autorización también. Entonces, todos los conceptos fundamentales están cubiertos. Obviamente, puedes hacer las cosas muy complejas, ¿verdad? Al igual que en REST, puedes hacer sistemas de autorización súper complejos, por ejemplo. Obviamente, los datos pueden ser súper sensibles. Puedes hacer una gestión de acceso a datos de bajo nivel. Entonces, digamos que alguien está accediendo a algunos libros que no se les permite ver. Puedes construir un sistema de autorización complejo en torno a eso y puedes filtrar lo que la consulta que proviene del usuario puede obtener a cambio. Entonces, filtrar respuestas esenciales. Puede volverse bastante complejo y todo eso es posible. Solo quería darte una idea de cómo las cosas podrían verse muy diferentes en <a href="/tags/graphql">GraphQL</a> y cómo <a href="/tags/graphql">GraphQL</a> es superior en esos casos de uso de acceso a datos en comparación con REST. Capacidades de filtrado súper complejas, como mencioné. Entonces, hay mucho más en ello. Aún puedes jugar con este masterclass aquí. Hay una guía paso a paso para cada cosa, pero espero que te hayas familiarizado con el concepto fundamental y lo básico y espero que puedas crear tu primera API de <a href="/tags/graphql">GraphQL</a> de forma independiente, tal vez incluso en tu futuro empleo. Y dicho esto, tal vez vuelva a las diapositivas porque hay un par de cosas que quería mencionar. Veamos. Necesito dejar de compartir desde esa pantalla a otra. Genial. Entonces, me gustaría volver a las conclusiones aquí. Lo que hemos visto cuando comenzamos a construir aplicaciones basadas en <a href="/tags/graphql">GraphQL</a> con algunos de nuestros clientes es que ganan mucha velocidad al construir aplicaciones. La razón es porque no necesitan codificar cada cosa y, oh, ahora hay un nuevo patrón de consulta y necesito acceder a estos 10 campos adicionales. 10 es una exageración, pero tal vez dos campos adicionales. Bueno, ahora, ¿adivina qué? Necesitas construir un parámetro de consulta y lógica subsiguiente en la capa de cálculo que obtiene esos datos de la base de datos. Entonces, hay mucho trabajo para cada cambio y cuando implementas <a href="/tags/graphql">GraphQL</a> para este tipo de aplicación intensiva en datos, especialmente lecturas, se vuelve súper, súper fácil de hacer. Y, por supuesto, debido a eso, son mucho más rápidos para llegar al mercado porque obviamente pasan menos tiempo codificando y simplemente configurando cosas, creando esquemas y eso es súper fácil de implementar, probar, etc. Por lo tanto, iterar mucho, mucho más rápido. También pueden hacer muchas cosas de seguridad. Ya hemos cubierto estas claves de API súper ingenuas y necesitamos usar herramientas o controles de acceso basados en identidad, pero pueden hacer más, incluso cosas más complejas con la autorización de <a href="/tags/lambda">Lambda</a>. Entonces, allí pueden construir esos sistemas de autorización complejos que pueden controlar quién tiene acceso a los datos, qué nivel de acceso tienen a los datos, qué campos pueden ser visibles. Por ejemplo, algunos tipos de usuarios pueden ver información de precios o información de suministro para el escenario de libros que teníamos. Algunos usuarios no pueden. Entonces, tal vez los usuarios que interactúan con los clientes solo pueden ver esos libros donde pueden comprar, cuánto cuestan, pero no pueden ver de dónde vienen. Y, por supuesto, todo eso conlleva un ahorro de costos asociado porque todo se ejecuta sin servidor. Entonces, no hay servidores detrás de escena que necesiten estar activos toda la noche. Todo el precio se calcula básicamente en función de cuántas solicitudes tienes y cuántas de esas, cuántos clientes tienes. Por lo tanto, se escala bastante bien. No tienes un gran costo inicial y viste lo fácil que fue implementarlo. Por lo tanto, para nosotros, pudimos hacerlo en, no sé, una hora y media o dos horas para crear una API completa y conectar esa API a una aplicación funcional. Y voilà, lo tenemos. No necesitamos esperar nada. Fue muy fácil para nosotros crearlo y tenerlo en funcionamiento. Y ahora, como no lo uso, no pago por ello. Como dejamos de usarlo. No es necesario apagar nada, no es necesario administrar nada. No hay sistema operativo, nada de eso, no hay preocupaciones de seguridad, etc. Y al final, nos gustaría dejarte con un par de conclusiones. Solo porque <a href="/tags/graphql">GraphQL</a> ahora es una nueva forma de hacer las cosas, no significa que sea la respuesta para todos nuestros problemas. REST todavía tiene su lugar en el mundo. Y no usaremos <a href="/tags/graphql">GraphQL</a> ahora para cosas súper simples que no están relacionadas con los datos. Entonces, no significa que no sea un reemplazo y también debemos mantener una mente abierta de que tal vez aparezcan otras nuevas tecnologías en el futuro. Y siempre necesitamos adaptarnos. Al igual que con los lenguajes de programación, hace 20 años, <a href="/tags/php">PHP</a> era el antiguo y viejo. <a href="/tags/php">PHP</a> no está en ninguna parte hoy en día. Entonces, siempre debemos tener una mente abierta hacia las tecnologías en evolución. Con <a href="/tags/graphql">GraphQL</a>, obtienes este poder sobre los datos. Y puedes construir mejores experiencias para tus usuarios, ¿verdad? Porque no necesitas ajustarte demasiado para obtener más información de la que realmente se necesita. Por lo tanto, no hay degradación del rendimiento, no se hacen demasiadas solicitudes, etc., pero también puedes obtener la cantidad correcta de datos. Por lo tanto, siendo extremadamente frugal con la conexión de red. También ten en cuenta, ¿verdad, que no todos los usuarios provienen de navegadores, Macs súper potentes, pueden venir de un dispositivo Android que tiene 10 años de antigüedad? Por lo tanto, ser frugal con los recursos que tienes disponibles es muy importante. Y, por supuesto, como dije, no es uno sobre el otro, dependiendo de los tipos de casos de uso que tengas, elige la tecnología adecuada. Y la seguridad es importante, ¿verdad? Dijimos en <a href="/tags/aws">AWS</a> que es una prioridad principal. Por lo tanto, siempre es muy importante no exponer tus API al público sin tener la seguridad adecuada, ¿verdad? Sin tener los requisitos de seguridad adecuados implementados. Y siempre monitorea lo que sucede en tu API, establece límites de velocidad, establece, no sé, restricciones geográficas. No hablamos de todo eso, pero hay servicios adicionales de <a href="/tags/aws">AWS</a>, pero no solo eso. Si construyes tu API de <a href="/tags/graphql">GraphQL</a> en otro lugar, asegúrate de que esté debidamente protegida antes de comenzar a exponerla, porque, lo creas o no, hay actores malintencionados que escanean Internet todos los días en busca de vulnerabilidades y formas de exponer, digamos, empresas y datos de clientes. Dicho esto, me gustaría agradecerte por venir con nosotros hoy y espero que hayas aprendido algo hoy que puedas aplicar, y también te invito a completar esta encuesta. Creo que también puedo ponerla en el chat. No estoy muy familiarizado con tus ofertas, pero vi que hay algunas

La funcionalidad de almacenamiento en caché que se puede vincular a la API de <a href="/tags/graphql">GraphQL</a>. Y así, estaba interesado en cómo se podrían resolver los problemas de validación de caché con <a href="/tags/graphql">GraphQL</a>, tal vez un poco. ¿Tienes alguna experiencia en mantener tus API de <a href="/tags/graphql">GraphQL</a> siempre actualizadas, o cómo funciona eso? ¿Es solo un TTL, o... Entonces, creo que estás hablando de la parte de Amplify. Como mencionamos, Amplify es tanto un servicio... bueno, tres cosas. Es un servicio, una <a href="/tags/cli">CLI</a> y un marco de biblioteca. Ya no estoy compartiendo la pantalla correcta, así que tal vez vuelva a compartirla en la correcta. Entonces, hay una funcionalidad en la biblioteca llamada <a href="/tags/data">Data</a> Sync, y creo que a eso te refieres. Entonces, esto es lo que probablemente estás buscando. Esto es más bien un patrón avanzado, donde básicamente, a través de la biblioteca, el <a href="/tags/frontend">frontend</a> puede realizar cambios locales, y una vez que se restablece la conexión con el punto final de <a href="/tags/graphql">GraphQL</a>, puedes pensar en ello como una conexión intermitente, ¿verdad? Estás en un tren, trabajando en tu aplicación, luego, 30 segundos, pierdes la conexión. Este <a href="/tags/data">Data</a> Sync, básicamente, registrará todos los cambios que realices, y una vez que recuperes la conexión, los enviará de vuelta al servidor. Esto funciona para, digamos, mutaciones o cambios que estés realizando. Para las consultas, también funciona de manera similar, o las suscripciones funcionan de manera similar. Entonces, digamos que estás sin conexión durante bastante tiempo, tienes un estado en tu <a href="/tags/frontend">frontend</a>, y una vez que vuelves a tener conexión con el servidor, tu estado local se sincronizará automáticamente con el servidor. Esto sucede, cómo decirlo, de manera transparente. No es necesario que <a href="/tags/code">code</a> nada, y luego tienes este intervalo de actualización en segundos, y también la funcionalidad de almacenamiento en caché. Sí. Pero esto es más un aspecto del <a href="/tags/frontend">frontend</a>. Tal vez, ¿y lo siento, estoy hablando del <a href="/tags/backend">backend</a>? Sí, exactamente. Tal vez pueda proporcionar algunas ideas al respecto. En realidad, nunca he profundizado demasiado en esto, pero sé que definitivamente es posible almacenar en caché en el lado del servidor. Luego, defines un TPL de caché. Por lo general, puedes definirlo por resolutor, y luego, para la caché, para mantener la caché actualizada, es tu responsabilidad invalidar la caché, y puedes hacer esto por resolutor. Si sabes que estás ejecutando una mutación, mientras estás haciendo la mutación, también harías una eliminación de caché en el resolutor <a href="/tags/code">code</a>. A medida que actualizas los <a href="/tags/data">data</a>, también invalidas la caché para el ID específico. Todo queda en manos de los ingenieros, por lo que no hay una solución específica de plataforma. Sí, eso es genial. De acuerdo, esa era mi pregunta. Muchas gracias. No hay problema. Que tengas un buen día. De acuerdo. Gracias a ti también. Te deseo lo mismo, y creo que podemos terminar aquí. Adiós, chicos. Adiós. Gracias a todos. Gracias.

Node Congress

Node Congress 2024

Build Modern Applications Using GraphQL and Javascript

Construye Aplicaciones Modernas Utilizando GraphQL y Javascript

El masterclass introduce el concepto de construir una aplicación utilizando la API de GraphQL en AWS. Destaca la importancia de aprender la última tecnología y su adopción por parte de las empresas. Se discuten los desafíos de construir APIs, con un enfoque en GraphQL como solución. El masterclass cubre temas como el diseño de esquemas, autenticación, autorización, actualizaciones en tiempo real e integración con aplicaciones frontend utilizando AWS Amplify.

Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.

Emanuel Scirlet

Miguel Henriques

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.