Transformando GraphQL: Infraestructura como código para desarrolladores front-end

Bueno. Hola a todos. Bienvenidos a mi charla. Esto es la transformación de GraphQL, infraestructura de pila completa como código. Y esta charla trata sobre cómo construir aplicaciones en la nube de pila completa como desarrollador front-end. Se divide en cuatro partes. Vamos a hacer una introducción a algunos de los contenidos sobre los que voy a hablar. Vamos a recorrer cómo hacer el modelado de datos utilizando GraphQL y la biblioteca de transformación de GraphQL. Luego haremos una demostración en vivo de prototipado rápido. Y luego les mostraré un ejemplo en vivo de una de las aplicaciones que he construido utilizando estas transformaciones de GraphQL.

Entonces mi nombre es Nader David. Soy un ingeniero de software. También soy autor y he hecho muchas cosas de código abierto y otras cosas. Y ahora mismo trabajo como defensor del desarrollador en el equipo de AWS Amplify. El último libro que he publicado se llama Full Stack Serverless. Y está muy relacionado con algunas de las cosas de las que estamos hablando hoy. Está disponible en O'Reilly. Así que si estás interesado en algunas de las cosas de las que estoy hablando, definitivamente recomendaría echar un vistazo a ese libro.

El equipo en el que trabajo, mencioné antes, es el equipo de AWS Amplify. Estamos enfocados en construir herramientas y SDK de nube de pila completa. Y uno de nuestros principales enfoques es atraer a nuevos desarrolladores al ecosistema de la nube, desarrolladores front-end y también mejorar la experiencia de desarrollo de muchas de las cosas que AWS tradicionalmente había hecho de manera diferente. Algunas de las diferentes infraestructuras que a la gente le gustaría usar son las mismas cosas que están utilizando estas grandes empresas a gran escala. Netflix, Airbnb e incluso Amazon están utilizando muchos de los servicios en los que nuestro equipo está tratando de construir abstracciones más fáciles de usar. Y eso es lo que está en el núcleo de algunas de las cosas de las que voy a hablar con la biblioteca de transformación de GraphQL.

Cuando digo herramientas y SDK de nube de pila completa, ¿a qué me refiero exactamente? Bueno, me gustaría comenzar desglosando Amplify y hablando de qué es Amplify. Amplify está compuesto principalmente por tres partes. Tenemos el hosting que tiene un hosting de sitio estático con una CDN global, muy fácil de configurar y ejecutar, y despliegues basados en Git y CI/CD basados en proyectos de Git. También tenemos una CLI que te permite, desde tu aplicación front-end, crear, actualizar y modificar servicios en la nube utilizando un enfoque basado en categorías que veremos en un momento. Y luego, después de crear los servicios a través de la CLI, tenemos un cliente que es, en realidad tenemos diferentes clientes para iOS, Web, React Native, y también tenemos componentes específicos del framework dentro de estas bibliotecas de cliente que te permiten interactuar con esos servicios después de haberlos creado.

Entonces, ¿cómo es el flujo de trabajo de la CLI? Es algo así. Inicializas un nuevo proyecto ejecutando Amplify Init. Agregas una nueva característica o actualizas una característica ejecutando Amplify add o Amplify update. Y cuando estás listo para implementar cualquier actualización, simplemente ejecutas Amplify push. Y luego, después de eso, puedes hacer actualizaciones adicionales ejecutando Amplify update. Y luego, después de haber creado estos servicios, importas los componentes o las diferentes bibliotecas de AWS Amplify. Así que en este ejemplo, tenemos storage, y luego puedes hacer llamadas a tu servicio de almacenamiento o tu servicio de API o cualquier servicio con el que estés trabajando. Entonces, realmente de lo que estamos hablando aquí cuando hablamos de nube de pila completa es que estás utilizando esta CLI y obtienes dos tipos diferentes de, supongo, artefactos de eso. Obtienes la infraestructura en la nube y luego obtienes la infraestructura local como código. Y también obtienes otro código local para cosas como flujos de autenticación y diferentes componentes de interfaz de usuario que también incluimos en nuestras bibliotecas de cliente. Pero realmente la parte principal de la que estamos hablando hoy es la infraestructura en la nube y la parte de infraestructura como código.

Entonces, ¿cuáles son algunas de las categorías que habilitamos en este momento? Bueno, dentro de cada una de estas categorías, generalmente hay un par de servicios diferentes. Por ejemplo, para API, puedes crear una API REST, un par de tipos diferentes de esas, o una API de GraphQL. Así que admitimos todas estas características diferentes, pero hoy nos centraremos principalmente en GraphQL.

La biblioteca de transformación de GraphQL es parte de algunas de las herramientas que te brinda la CLI. ¿Y qué es exactamente la biblioteca de transformación de GraphQL? Primero echemos un vistazo a eso antes de adentrarnos en una comprensión más profunda de lo que hace exactamente esta biblioteca. Así que hablemos de cómo construir una API de GraphQL desde cero. ¿Qué necesitarías para que esto suceda? Digamos que necesitas una aplicación de tareas y necesitas una forma de crear, actualizar y eliminar tareas. Primero comenzarías con tu esquema de GraphQL y el esquema podría tener un tipo de tarea. Luego crearías, actualizarías y eliminarías mutaciones. También podrías tener una consulta para obtener una tarea y listar todas las tareas. Y luego podrías tener suscripciones que crearías para cuando se cree, actualice y elimine una tarea. Así que necesitarías crear todo ese esquema. Luego necesitarías tener algún tipo de base de datos o fuente de datos que interactúe con tu API de GraphQL. Y luego necesitarías crear los resolutores que mapean entre el esquema con las operaciones de GraphQL y las fuentes de datos.

Poner todo esto junto es bastante trabajo, pero además de eso, debes pensar en cosas como autorización, autenticación, seguridad, cualquier cosa que pueda ser vulnerable en cuanto a una API de GraphQL se refiere, cosas como consultas anidadas y cosas así. Entonces, cuando estás construyendo una API, no solo estás pensando en tu infraestructura, sino que también estás pensando en el mantenimiento y todo este código adicional con el que estás lidiando. Servicios como AWS AppSync, que es un servicio de GraphQL administrado, facilitan esto. Y eso es esencialmente lo que impulsa la biblioteca de transformación de GraphQL en el fondo. Así que usando estas directivas, podemos tomar el servicio de GraphQL administrado que es AppSync, usar nuestro esquema de GraphQL local con Amplify y agregar una variedad de nuevas piezas de configuración, así como diferentes características, simplemente usando estas directivas.

Entonces, aquí hay algunas de las que habilitamos en este momento, y las que vamos a explorar en esta charla son @model, @auth y @connection. Vamos a ver exactamente qué hacen. Cuando trabajas con la biblioteca de transformación de GraphQL, ¿cómo funciona realmente? Bueno, solo piensa en un esquema de GraphQL típico. Simplemente escribes toda la definición del esquema que necesitarías. Con la biblioteca de transformación de GraphQL, luego decoras tus tipos base con estas diferentes directivas. Luego ejecutas una compilación. Y luego, después de ejecutar esa compilación, generamos infraestructura como código. Y cuando ejecutas la implementación, implementamos esa infraestructura para ti basada en esas directivas.

Echemos un vistazo un poco más en profundidad a algunas de estas directivas. @model es realmente una de las más poderosas. Y esta directiva genera bases de datos, resolutores, operaciones CRUD y suscripciones para cualquier tipo base.

Entonces, por ejemplo, necesitamos una aplicación de comercio electrónico. Todo lo que necesitamos hacer es crear este tipo base de producto y la directiva @model generará una tabla DynamoDB. Generará operaciones de creación, lectura, actualización y eliminación para el producto. También crearemos suscripciones para propietario, creación, propietario, actualización y propietario, eliminación, y luego generaremos todos los resolutores que mapean entre las operaciones de GraphQL y esa fuente de datos. Ejecutas una compilación y esto es más o menos lo que obtienes, esas tres cosas que acabo de mencionar.

También ofrecemos una forma de modelar diferentes reglas de autorización para un tipo. Por ejemplo, digamos que tenemos este tipo de publicación y podrías pensar en un blog o algo así, y usando la directiva @auth y pasando la propiedad allow owner, básicamente estamos diciendo, ok, solo el propietario de esta publicación puede actualizar, eliminar o incluso leer esta publicación, pero lo más probable es que tengas una combinación de diferentes roles. Por ejemplo, si piensas en un blog o incluso en algo como Instagram o Twitter, normalmente tienes una combinación de un par de tipos diferentes de autorización. Esos dos tipos suelen ser una combinación de público y privado. Usando esta combinación de reglas aquí, permitimos a los propietarios crear, actualizar y eliminar, y luego después de que la operación haya sido exitosa y hayas creado, actualizado o eliminado una publicación, entonces cualquiera puede leer la publicación. Tenemos ese acceso público para la lectura, acceso privado para la actualización y eliminación. Y luego también puedes agregar reglas adicionales allí, como privilegios de administrador y cosas así. Y luego también tenemos la directiva @key que te permite configurar patrones adicionales de acceso a datos en tus diferentes tipos. Así que piensa en una aplicación nuevamente, tal vez algo como una aplicación de comercio electrónico donde tienes un tipo de inventario. Por defecto, puedes obtener una pieza de inventario por ID, puedes listar todo el inventario, pero eso es todo lo que creamos por defecto. Usando la directiva @key, podemos agregar patrones adicionales de acceso a datos. Podemos hacer cosas como obtener por ID de almacén, obtener dentro de un rango de cantidad de inventario, podemos obtener dentro de un rango de precios. Y al hacerlo, para configurarlo, todo lo que necesitamos hacer es especificar el campo que nos gustaría consultar y luego el campo de consulta, que es la consulta de GraphQL que vamos a crear y darte de forma predeterminada. Entonces, ¿cuál es el desafío que me gustaría hacer para esta charla? Bueno, me gustaría seguir adelante y tomar estas transformaciones de GraphQL y construir una API en solo un par de minutos. Y lo que me gustaría hacer es construir esta API en unos cinco minutos. Necesita tener un esquema completamente mapeado basado en un par de tipos base. Quiero tener las bases de datos para cada tipo, quiero tener los resolutores, también quiero mapear las relaciones entre los diferentes tipos, y quiero definir reglas de autorización, y quiero simular esto localmente. Así que vamos a intentar hacer eso. Voy a ir a mi terminal. Aquí en nuestra terminal, estamos comenzando con un proyecto básico de Amplify que tiene la autenticación habilitada a través de Amazon Cognito User Pools, que es un servicio de autenticación administrado, algo así como Auth0. Y lo que vamos a hacer ahora es agregar una API de GraphQL. Para hacer eso, voy a ejecutar amplify-add-api. Esto nos guiará a través de todos los pasos.

Entonces, vamos a elegir GraphQL, vamos a darle el nombre de la API y vamos a elegir un tipo de autenticación predeterminado. Para el tipo de autenticación o autorización, voy a elegir Cognito User Pool, que es un servicio de autenticación administrado, pero vamos a agregar un tipo de autenticación adicional para acceso público en un momento. Para las configuraciones avanzadas, voy a elegir sí para poder agregar ese tipo de autenticación adicional. Y voy a elegir API key para acceso público. Le daremos una expiración. Seleccionaremos no para la detección de conflictos. Si quisiéramos soporte sin conexión, elegiríamos sí. Si tuviéramos un esquema con el que quisiéramos comenzar y ya lo tuviéramos creado localmente, podríamos hacer referencia a eso.

Pero no lo haremos. En su lugar, vamos a elegir una creación de esquema guiada y comenzar con una de las plantillas que ofrece Amplify. Voy a pegar el esquema con el que estamos comenzando, que será como una aplicación de comercio electrónico donde tenemos un tipo de producto y reseñas. Los administradores pueden crear productos y los usuarios pueden dejar reseñas.

Para hacer que esto funcione, vamos a utilizar la biblioteca de transformación de GraphQL para crear operaciones CRUD, suscripciones, resolvers y tablas para cada uno de estos dos tipos. De esta manera, podremos crear, leer, actualizar y eliminar productos y reseñas, y también podremos asignar suscripciones a ellos. También utilizamos el tipo de autenticación para definir algunas reglas de autorización. Para el tipo de producto, permitimos que los administradores tengan acceso completo para crear, actualizar y eliminar productos, pero no permitimos modificaciones por parte de otros usuarios. Sin embargo, permitimos acceso público y privado para la lectura, lo que significa que los usuarios pueden leer productos si están registrados o si solo están visitando el sitio.

Lo siguiente que tenemos es la directiva de conexión en el tipo de reseña, que establece una relación de uno a muchos entre un producto y muchas reseñas. De esta manera, cuando creamos una reseña, podemos especificar a qué producto pertenece. Luego, podemos realizar consultas de reseñas por producto y también consultar tanto el producto como las reseñas en una sola operación.

A continuación, veremos el tipo de reseña. Aquí tenemos reglas similares, pero hay un poco más de cosas sucediendo. Permitimos acceso de administrador para todo, y también permitimos acceso de propietario para que cualquier persona pueda crear una reseña y también actualizar o eliminar sus propias reseñas si lo desean. Permitimos acceso público para leer reseñas y también acceso privado para leer reseñas, lo que significa que si estás registrado o no, aún puedes leer reseñas. Luego podemos guardar esto y volver a la línea de comandos, porque eso es todo lo que necesitamos hacer. Esto va a inspeccionar nuestro esquema y asegurarse de que sea válido. Si lo es, nos dará un mensaje diciendo que se ha compilado correctamente.

Ahora podemos simular esto localmente antes de implementarlo simplemente ejecutando 'amplify mock'. Esto va a inspeccionar nuestro esquema nuevamente y va a simular la tabla de productos o la tabla de reseñas. Generará todos los diferentes resolvers y esquemas y cosas adicionales que necesitaremos. También podemos hacer una cogeneración local si estamos interactuando con esta API desde un proyecto de JavaScript. Voy a elegir sí para todas esas preguntas. Ahora tenemos un servidor gráfico local en ejecución en localhost. El servidor gráfico está funcionando y ahora podemos comenzar a realizar operaciones.

Quiero actualizar la autenticación para ser yo mismo. Así que voy a iniciar sesión como debit tres y generar un token. Y lo que nos gustaría hacer es crear una mutación para crear un producto. El producto tendrá una descripción y un nombre. Vamos a crear esto. Y boom, obtenemos un error de no autorizado porque no hemos iniciado sesión como administrador. Así que nuestras reglas de autorización están funcionando hasta ahora. Vamos a simulamos como un administrador y probar esto. Ahora que somos un administrador, deberíamos poder realizar esta operación. Así que la creación del producto es exitosa.

A continuación, vamos a crear un comentario o una reseña. Para la creación de la reseña, vamos a decir, que queremos tener un comentario, una calificación y vamos a necesitar especificar el ID del producto. Así que dejaremos ese ID de producto ahí. El comentario es: zapatos increíbles. Y vamos a actualizar nuestra autenticación y decir que ahora somos un usuario diferente. Y parece que tengo algo sucediendo aquí. Parece que no necesito algunos de estos campos que se están autocompletando. Bien, genial. Así que tenemos los campos que queremos que son Comentario, Reseñas del Producto, ID y Calificación. Así que debería poder probar esto. Podemos hacer esto ya que solo somos un usuario registrado. Así que hemos creado nuestra reseña.

Y finalmente, quiero, supongo, por ahora, mantengámonos iniciados como este usuario. Y queremos consultar todos los productos. Y vamos a devolver todos los productos. Pero ahora tenemos esta relación entre productos y reseñas. Así que en realidad podemos obtener las reseñas de un producto. Así que vamos a obtener todo eso y ejecutar esta consulta. Y ahí puedes ver que nosotros, como usuario registrado, podemos consultar productos y reseñas. También queremos probar esto como usuario público.

Entonces, ahora estaremos conectados o desconectados. Y estamos simulando el acceso público. Vemos que eso aún funciona. Así que hemos creado esta aplicación básica con reglas de autorización, todo implementado en solo unos minutos localmente. Y podemos volver atrás. Y si queremos implementar esto en nuestros servicios de backend, podemos ejecutar Amplify Push.

Entonces eso es todo en esa parte. Volvamos a mis diapositivas. Y tengo un par de ejemplos. Pero solo voy a mostrar uno ahora. Esta es una aplicación de votación que construí. Y esta es una aplicación de votación muy, muy escalable. Se llama this-or-that.dev. De hecho, la he probado con unos pocos millones de operaciones en el transcurso de un minuto. Y todo se escaló y funcionó perfectamente. Diría que no recomendaría hacer eso, porque te costará alrededor de $0.25 o algo así por cada millón de operaciones. Así que piénsalo. Pero simplemente pruébalo y se escalará. Llegará a ese punto. Solo voy a mostrarte el esquema con el que trabajé. Así que tengo un tipo de encuesta. Y tengo un tipo de candidato. Tengo algunas reglas de autorización. Y tengo algunas directivas at-key que permiten patrones adicionales de acceso a datos. Pero básicamente creas una encuesta. Luego creas un candidato para esa encuesta. Y luego permites votar en esa encuesta. Para probar esto, voy a abrir mi navegador y voy a this-or-that.cloud. Y esto está funcionando en vivo. Y pueden probarlo.

Y lo que me gustaría hacer es crear una nueva encuesta. Y quiero que todos aquí en esta charla prueben esto. Así que voy a decir que esto va a ser llamado Tejas o Natter. Y voy a decir Tejas o Natter. Y esto va a ser tal vez quién tuvo la mejor charla o algo así en este evento, ¿verdad? Porque Tejas es mi amigo. Esto es más una cosa amistosa.

Lo que me gustaría que hagas es ir a this-or-that.cloud slash Tejas o Natter y votar. Y lo que deberías ver es si abrimos un par de pestañas a la vez, deberías poder ver las actualizaciones en tiempo real que están sucediendo aquí. Así que si voto Tejas un par de veces, vuelvo aquí y voto Natter. Verás que se refleja en tiempo real. Y si quieres compartir esto, puedes copiarlo en tu portapapeles y compartirlo y seguir adelante.

Así que sí, esto será divertido. Estoy deseando ver los votos en esto cuando la gente empiece a participar. Y eso es todo para esta charla. Así que gracias por ver mi charla. Puedes encontrarme en Twitter en Davit3. Si tienes alguna pregunta, me encantaría responderlas en la sesión de preguntas y respuestas aquí, o después si tienes alguna pregunta dentro de una semana, un mes después, contáctame en Twitter. Estaré encantado de ayudar. Y eso es todo. Así que muchas gracias por venir a mi charla.

Wow, Natter. Esa fue una charla muy buena. Muchas gracias por iluminarnos a todos. Tenemos algunas preguntas que han llegado. Así que cambiemos a las preguntas, ¿de acuerdo? Hagámoslo. ¡Salud! Sí, hagámoslo. ¿Puedes acompañarme al escenario? Sí. Genial. Voy a empezar leyendo la primera pregunta para ti. De Iradir, ¿la combinación de precios difíciles de predecir versus, digamos, una tarifa mensual para el alojamiento normal, además del problema de la dependencia del proveedor, es algo que me aleja de ello. ¿Cómo puedo asegurarme de que dentro de seis meses, no estaré pagando varios dólares al mes, o tendré que desactivar mi aplicación? Sí, esa es una pregunta muy popular. Es una muy buena pregunta, realmente. Creo que es una de esas cosas que debes tener en cuenta todos los compromisos, el alcance completo del proyecto cuando se trata de cuánto tiempo estás invirtiendo en desarrollar algunas de estas características, los costos de mantenimiento y los precios reales. Así que digamos que estás aprovechando un servicio gestionado, no solo de AWS, sino realmente de cualquier proveedor de la nube, o cualquier proveedor de servicios gestionados, puedes pensar en cosas como Auth0 o Cloudinary, AWS, GCP. Todos tenemos nuestras propias versiones de estas cosas. Digamos que quisieras crear tu propia autenticación desde cero en lugar de tal vez usar el servicio de autenticación de AWS o algún servicio de autenticación. ¿Cuánto tiempo vas a pasar construyendo eso desde cero? ¿Cuánta experiencia tienes en ese dominio? Todas estas cosas entran en juego. Y cuando comienzas a pensar en el costo total de propiedad, construyendo todo esto, asegurándote de que sea seguro, asegurándote de que cuando tu aplicación se expanda, siga siendo segura. Las horas que podrías pasar haciendo eso o incluso contratando a otras personas para que construyan esas cosas por ti, ahí es donde está el verdadero compromiso. Por lo general, pagarás extra por algún tipo de servicio gestionado o incluso un servicio de la nube. Pero lo que obtienes a cambio es que alguien más se haga cargo de todo ese código, se haga cargo de las preocupaciones de seguridad. Y al final del día, muchas veces, tiene más sentido utilizar uno de estos servicios de la nube. Pero otras veces, tiene más sentido construirlo tú mismo. Así que diría que no siempre diría que vayas con el servicio de la nube. Diría, mira tu experiencia en el dominio, mira a tu equipo, mira el costo total de propiedad, y luego toma esa decisión.

Sí, esa es una excelente respuesta. Muchas gracias. Otra pregunta fue si Amplify es estrictamente para AWS. Sí, Amplify es estrictamente para AWS. Es un proyecto de código abierto. Teóricamente, también se puede utilizar para otras cosas. Y parte del código front-end, parte del React y JavaScript y cosas del lado del cliente se pueden utilizar de forma agnóstica a cualquier proveedor de la nube. Por lo tanto, hay algunas características que están ahí, pero en su mayoría el framework está construido para soportar AWS.

Sí, absolutamente. Quiero recordarles a todos que Discord sigue abierto. Todavía estoy revisando. Así que si tienes alguna pregunta para ninguno de los dos, avísame o avísale a todos nosotros, en realidad. Tengo algunas preguntas propias. Me encantaría saber cuál es tu opinión sobre el futuro de la infraestructura como código, hacia dónde nos dirigimos. Creo que nos dirigimos hacia abstracciones mejores y más comprensibles, más limpias y más concisas sobre la infraestructura como código. Si miras cualquier sistema distribuido que la gente está construyendo en este momento en la naturaleza de todos modos, la mayoría de ellos están construidos sobre la infraestructura como código, pero entender cómo implementar un sistema complejo y cómo entender cómo unir todas las piezas requiere mucho conocimiento del dominio y lleva mucho tiempo adquirir ese conocimiento. Y creo que lo que estás viendo son estas abstracciones como Amplify, pero también hay otras cosas, donde la gente te permite usar un lenguaje más conciso, mejores cosas como el framework serverless, es un buen ejemplo, donde construyeron una versión más concisa de la infraestructura como código, donde aún estás escribiendo infraestructura como código, pero es menos código y tienes que saber menos sobre los servicios subyacentes. Y luego Amplify es aún un nivel más alto en ese sentido, donde solo estás ejecutando comandos que tienen que ver con categorías en lugar de los nombres reales de los servicios y cómo todo funciona junto. Creo que verás cada vez más cosas en ese sentido. Creo que mucha gente está reconociendo el poder de la infraestructura como código, pero también se dan cuenta de lo complicado que es realmente construir a un nivel muy bajo. Por lo tanto, lo están haciendo más fácil para personas como yo, que tradicionalmente soy un desarrollador front-end, poder construir estos sistemas escalables en estas plataformas realmente potentes sin tener que pasar cinco años entendiendo cómo funciona todo a nivel de bajo nivel simplemente proporcionando estas mejores abstracciones.

Sí, maravilloso. Y si hay personas que quieren aprender más sobre esto, ¿dónde recomendarías que comiencen? Quiero decir, si estás buscando aprender más sobre Amplify en general, definitivamente deberías consultar la documentación. Así que sería docs.awsamplify, creo, .com. Tenemos una nueva sección de guías que se lanzará a fin de mes que profundiza y proporciona muchos tutoriales detallados. Pero por ahora, toda la documentación está allí para todas las diferentes APIs que admitimos y cosas así. Si estás buscando aprender más sobre la infraestructura como código en general, definitivamente también deberías consultar Serverless Framework. Deberías consultar Terraform, que te permite escribir código en todos los proveedores de nube, no solo en AWS. Y esas tres serían prácticamente las cosas que definitivamente deberías consultar si estás interesado.

Súper genial, de acuerdo. Y luego, ¿cuál es, si hay una cosa que las personas deberían recordar de tu charla, qué te gustaría que fuera? Creo que, sabes, estás viendo mucho trabajo por ahí que facilita a las personas tener un único conjunto principal de habilidades.

Para mí, eso es como JavaScript y el desarrollo front-end y poder comenzar a usarlo para crear aplicaciones mucho más poderosas o construir aplicaciones más poderosas y más como aplicaciones full-stack que típicamente solo podíamos hacer en el pasado. Como desarrollador front-end, estaba realmente limitado a construir solo el lado del cliente de la aplicación. Y luego otras personas construían los servicios y yo me encargaba de conectar estos servicios.

Ahora, lo que estamos viendo son todas estas diferentes abstracciones como Amplify y otras cosas que están disponibles, ya sabes, Firebase, Netlify, todos estos actores están haciendo cosas similares. Ahora puedes usar tus habilidades de front-end pero también puedes escribir la parte del backend sin entender todos los detalles que intervienen en la construcción de todo esto. Simplemente estamos obteniendo estas API que podemos consumir y que podemos controlar utilizando el conocimiento del dominio que ya tenemos.

Sí. Muy bien. Gracias por eso. Como hoy tenemos un pequeño equipo de cocina, me encantaría preguntarte, ¿eres un buen cocinero, verdad? Puedo cocinar una cosa y es a la parrilla, cualquier cosa a la parrilla, puedo cocinar eso. Aparte de eso, mi esposa es una cocinera increíble. Así que la apoyo en la cocina, voy al supermercado, compro cosas y limpio y hago todas las tareas de apoyo. Ella es la experta y tengo mucha suerte. Soy como el sous chef, sí.

Genial, y entonces, ¿cuál es tu comida reconfortante favorita? Diría que cualquier cosa con carbohidratos porque realmente no como muchos carbohidratos. Así que cuando tengo la oportunidad, como 10 veces más de lo que probablemente debería. Wow, okay, bueno, eso está bien. Gracias por compartir eso con nosotros. Y muchas gracias de nuevo por tu charla. Creo que vamos a hacer un pequeño descanso, pero primero quiero asegurarme de que todos sepan que aún pueden seguir hablando con Nader en la sala de ponentes. Así que muchas gracias por unirte a nosotros. Gracias por tenerme, sí. Absolutamente, fue un placer.