Mejora el rendimiento de tu aplicación con trabajos en segundo plano

Básicamente, esta es una charla uno a uno sobre trabajos en segundo plano, una introducción muy suave. Si no sabes nada sobre trabajos en segundo plano, no te preocupes. Pero si sabes mucho, puedes apoyarme riéndote de mis chistes.

Esto fue una prueba. Soy Sylvia Vargas y me preguntaba qué información podría ser relevante para esta maravillosa audiencia. Y se me ocurrió un pequeño juego. Así que el juego es así. Diré un dato sobre mí, y si tenemos eso en común, haz un ruido, cualquier ruido que quieras. Un calentamiento. Estoy muy feliz de estar aquí. Vale. Me encantan los pierogi. Se pondrá cada vez más oscuro, así que prepárate. Me encantan las palomas y tengo una familia de palomas viviendo en mi balcón. Vale. Vale.

Y, bueno, algunos de ustedes pueden conocerme porque hice algunas contribuciones a esta página llamada React docs. Esta es la página. Y anteriormente... ¿Alguien? No? Vale. Y anteriormente, estaba a cargo de las relaciones con los desarrolladores en Ingest, perdón, en StackBlitz, y ahora me uní recientemente a Ingest como líder de relaciones con los desarrolladores. Como les dije, esto se volvió cada vez más oscuro. Pero aquí hay algo que tal vez todavía tengamos en común. El dato curioso sobre mí es que realmente me encanta trabajar en proyectos paralelos. Porque es... ¿No? ¿No? Porque todo es alegría y diversión. Y básicamente no tienes que preocuparte por todas las necesidades comerciales. Solo puedes enfocarte en la experiencia del usuario. Y como muchas veces eres tu propio y único usuario, siempre estarás feliz. Pero, ya sabes, este no es el caso con las aplicaciones de producción reales.

En el desarrollo de productos reales, lo que el usuario ve es, ya sabes, a menudo solo la punta del iceberg. La mayoría del software es más complicado y mucho más aterrador de lo que pensamos debido a los requisitos comerciales. Así que veamos un escenario de la vida real. Imagina que te unes a una nueva y popular aplicación de reserva de restaurantes. La aplicación está en Next.js porque todos los que trabajan allí son hipsters. Y tu jefe te pregunta cuánto tiempo te llevará construir un flujo de registro. Así que recibes una lista de requisitos del gerente de producto.

De acuerdo. Echemos un vistazo. Ya sabes, tienes un buen café con leche. Estás bastante relajado. Es un martes típico. Entonces necesitas, ya sabes, security y autenticar al usuario. Debería sostener el café con leche. Debes agregar al usuario a la base de datos. Debes usar... Agregar al usuario a la lista de correo y también enviar un correo de bienvenida. Ya sabes, miras eso. Fácil. Porque hoy en día es mucho más fácil construir esto que hace cinco años, ¿verdad? Porque ahora puedes usar, por ejemplo, Clerk para autenticación, Superbase para base de datos, MailChimp para una lista de correo y Resend para correo electrónico.

Así que estás como... Trabajo hecho. Eso es todo. Tal vez este también sea el final de mi presentación aquí. Pero no, hay más. Entonces, ya sabes, das un gran sorbo a tu café helado y vuelves a jugar Wordle o leer uno de los miles de hilos de Dan Abramov sobre React componentes del servidor. Así es como se vería el código. Crearías un usuario en la base de datos. Enviarías el correo de bienvenida y luego agregarías al usuario a la lista de correo. Y esto parece simple.

Y eso es bueno porque nos gusta lo simple. No diría que nosotros, ya sabes, como desarrolladores, somos especialmente perezosos, pero no nos gusta complicar nuestra vida. Y así, construir aplicaciones utilizando servicios de terceros es inteligente y generalmente facilita tu vida.

Pero, ¿dónde está el problema? Bueno, el inconveniente ahora es que hemos creado una aplicación distribuida donde no tenemos ningún control sobre gran parte de la infraestructura en la que nuestro servicio depende. Por ejemplo, los servicios pueden ser realmente lentos. Usar un correo electrónico, incluso en un buen día, puede llevar medio segundo. Así que ahora tenemos un problema. Tenemos un code bloqueante en el camino crítico de la solicitud.

En otras palabras, nuestro usuario está perdiendo tiempo porque estamos haciendo más lenta nuestra API. Pero, bueno, debemos tener en cuenta que la experiencia del usuario no debe verse afectada debido a los requisitos comerciales. ¿Cómo lo estamos haciendo hasta ahora? ¿Es rápido? No. ¿Es confiable? Tampoco.

Así que imagina que estás agregando al usuario a una lista de correo y el servicio se cae. Entonces tenemos que gestionar los reintentos. Uno, dos, tres, cuatro veces. ¿Y si algo falla permanentemente? Ahora tienes que agregar estos errores a un servicio de registro. Y también necesitas idear, ya sabes, un sistema de recuperación. Así que ahora la estimación para construir esta característica tan simple pasa de, ya sabes, días a semanas. Y también tienes que construir y gestionar toda la infraestructura y los procesos.

Además, por cierto, las fallas parciales pueden ser realmente complicadas. Así que has agregado al usuario a la database pero no le has enviado un correo electrónico. Así que ahora tenemos tres opciones. Primero, podemos ignorar el error, lo que significa, ya sabes, que el usuario no estará en la lista de correo. Segundo, bueno, podemos mostrarle el error al usuario, lo que probablemente resultará en la pérdida de un cliente. O tercero, lo peor de todo, ya sabes, el usuario intentará registrarse nuevamente, tonto. Así que veamos eso. Así que supongamos que, ya sabes, el usuario recibe el error e intenta registrarse nuevamente. Pero ahora, usuario, quiero decir, db.user.create dará error porque hay un duplicado. Buena suerte recuperándote de eso. Así que este es el lío en el que estamos metidos.

La aplicación en la que estamos trabajando tarda una eternidad en funcionar. Me lleva una eternidad construir. Sabes, seré más lento en mi trabajo porque tengo que gestionar todo el backlog de soporte. Y sabes, aún no estoy lidiando con las fallas persistentes. Así que todos están descontentos.

Mi jefe está descontento. Estoy estresado. No puedo dormir. Como un desastre. Pero hay una solución. Podemos hacer que nuestro code sea más rápido y confiable moviendo tareas no bloqueantes a trabajos en segundo plano.

Ahora, por lo general, cuando hablamos de mover tareas no bloqueantes a trabajos en segundo plano, hablamos de colas. Y las colas son excelentes para procesos intensivos de data que no se ejecutan en el hilo principal porque se ejecutan de forma asíncrona. Entonces, en términos simples, puedes pensar en las colas de esta manera. Sabes que una vez que agregas algo a la cola, llegará a su destino uno por uno. Lo que sucede en la cola no afecta otras partes de la infraestructura. Así que la entrega está garantizada.

Pero lo que sucede después de que el mensaje llega al consumidor depende de ti. Está en tus manos. Entonces, la desventaja aquí es que una vez que tomas algo de la cola, el resto depende de ti y al servicio de colas simplemente no le importa. Esto significa que las colas funcionan muy bien cuando tu aplicación es simple. Pero cuando crece en complejidad, cuando tienes mucho éxito y tienes miles de usuarios o si es distribuida, de repente necesitas preocuparte por una gran cantidad de infraestructura adicional que debes construir.

Entonces, por ejemplo, tal vez necesites pensar en la concurrency porque quieres poder controlar cuántos pasos se ejecutan al mismo tiempo. O tal vez la persistencia y gestión del estado porque ahora que tienes una aplicación distribuida, quieres compartir el estado entre diferentes funciones y colas. O el manejo de errores, como dije, ya sabes, ¿qué pasa si otro proveedor de servicios tiene una interrupción? Entonces, ahora tendrías que gestionar los reintentos, las fallas y los tiempos de espera. Eso es mucho trabajo. Y como dije, no somos especialmente perezosos, pero también nos gusta que nuestra vida sea simple. Pero hay una solución. Hay una solución. Y diría que son los flujos de trabajo duraderos que combinan la ejecución duradera y el control de flujo.

Entonces, la Ejecución Duradera es similar a las Colas de Mensajes. Pero en lugar de tener que separar tu infraestructura de confiabilidad de tu aplicación, puedes definirlo todo como parte de tu code. Y lo verás en un segundo. Bueno, podemos decir que la Ejecución Duradera es ahora este paradigma de moda. En esta charla, hablaré principalmente sobre Ingest. Tomaré eso como ejemplo, pero, ya sabes, hay otros proveedores. De hecho, CloudFlare acaba de anunciar que lanzarán Flujos de Trabajo Duraderos. Afortunadamente, la API de CloudFlare es la misma que la de Ingest, por lo que puedes empezar a jugar con ella de inmediato. Pero de todos modos, movamos tareas no bloqueantes a trabajos en segundo plano. Entonces, primero agregarías Ingest al proyecto y Ingest aquí es una capa de confiabilidad para tu aplicación. Con Ingest, defines funciones o flujos de trabajo dentro de tu base de code utilizando su SDK y luego lo sirves a través de un punto final HTTP en tu aplicación. Así que, puedes pensar en ello como que se encarga de ejecutar tus funciones de forma confiable de manera asíncrona. También hay un panel de control, lo verás en un momento. Puedes monitorear, ya sabes, y debug todas las funciones. Así que volvamos a nuestra aplicación. Oh. Así es como se ve nuestra aplicación ahora. Y ahora vamos a agregar la capa de confiabilidad que es Ingest. Primero vamos a envolver esta función en la función Ingest.create y como puedes ver, estamos proporcionando un nombre de evento allí. Entonces, cuando el usuario se registre más adelante, dispararemos un evento con este nombre. Eso le dirá a Ingest que ejecute la función.

Entonces, así es como se vería en el code. Primero creamos la función, luego proporcionamos el nombre del evento y finalmente invocamos nuestro code existente de antes. Y ahora haremos lo mismo para la otra función.

Y aquí también puedes notar que estamos usando exactamente el mismo nombre de evento y esto es porque queremos que estas dos cosas se activen al mismo tiempo cuando el usuario se registre. Por cierto, este botón se llama comúnmente fan out.

Entonces, ahora cuando el usuario hace clic en el botón, enviaremos un evento a Ingest. Y así es como se ve en el code. En lugar de invocar estas funciones directamente, estamos activando un evento en Ingest. Como mencioné antes, exponemos nuestras funciones a Ingest como un punto de conexión HTTP y luego utiliza este punto de conexión para ejecutar la función muy específica cuando se activa el evento muy específico.

Y este es el punto de conexión. Ingest utiliza este punto de conexión para descargar las definiciones de las funciones y ejecutarlas. Así que aquí tenemos el flujo completo. Básicamente, Ingest llamará a las funciones correctas en el momento preciso que desees. Y luego en el panel de control, recibirás una notificación de que se activó un evento que a su vez llamó a dos funciones. Verás que se completaron y también cuándo.

De acuerdo. Pero, ¿qué sucede si hay un fallo? Bueno, veamos eso. Imaginemos que Ingest invoca una función y falla con un error code. Ingest lo volverá a intentar una y otra vez hasta que finalmente tenga éxito. Y no tienes que preocuparte por eso. Además, también obtienes un registro detallado en el panel de control de lo que sucedió. Y sé que, bueno, voy a ser sincero contigo. Sé que es difícil de creer, pero a veces, ya sabes, los errores son persistentes en nuestra aplicación no debido a problemas del servicio, sino porque hay errores en nuestro propio code. Dura verdad. En estos casos, simplemente puedes debug con Ingest y luego console y luego no perderás ningún data. Puedes recuperarlo muy fácilmente. Puedo mostrarte eso más tarde. Y ya sabes, una vez y sí, simplemente puedes volver a activar todos los eventos y recuperar los data.

Entonces, queríamos que nuestra aplicación fuera más rápida. Así que movimos las tareas no bloqueantes de la ruta crítica del usuario a los trabajos en segundo plano.

Pero también obtuvimos confiabilidad como una buena adición. Ahora que tenemos acceso a esta infraestructura, veamos qué más podemos hacer. Entonces, esta es nuestra aplicación en este momento. Aún no te lo he dicho, pero en realidad Ingest te permite programar tareas en el futuro y orquestar procesos de varios pasos.

Entonces, veamos el correo electrónico enviado aquí. Aquí simplemente estamos enviando un correo electrónico de bienvenida. Pero si alguna vez has hablado con algún gerente de producto, sabrás que siempre es bueno aumentar la retención de usuarios. Entonces, ¿cómo podríamos hacer eso? Por ejemplo, podríamos enviar una campaña de goteo de correo electrónico de activación en la primera semana. Entonces, ¿cómo lo hacemos? Primero, creemos una función de Ingest que se react al mismo evento.

Hasta ahora, hemos estado hablando del patrón que se llama `fan out`, donde tienes múltiples funciones que se activan con el mismo evento. Sin embargo, muchas tareas requieren una progresión secuencial. Y aquí estamos construyendo una campaña de goteo de marketing. Por lo tanto, tiene sentido expresar el code, toda la línea de tiempo, como un code procedural. Por lo tanto, utilizaremos pasos de Ingest dentro de la función. Aquí estamos usando, puedes ver `ingest step dot run`. Y de esta manera, este code específico se reintenta automáticamente si falla. Pero si se ejecuta correctamente, nunca se reintentará nuevamente. Ingest lo omitirá. Y luego también lo veremos en acción en un momento.

Primero, estamos enviando un correo electrónico de bienvenida y esta es exactamente la misma parte que hicimos antes. Luego, Ingest pausará la ejecución de esta función durante cuatro días. Y aquí estamos usando `ingest dot sleep`. Desde la perspectiva del programador, se ve similar a simplemente poner, ya sabes, `set time out`. Pero en realidad, en segundo plano, Ingest se encarga de la programación por ti. Entonces, eso significa que tu función de servicio no se ejecuta durante cuatro días. Y no tienes que vender un riñón para pagar tu factura de AWS, lo cual siempre es bueno. Entonces, ahora este es el último paso. Y ese es el último correo electrónico con tips. Entonces, si hay un fallo en uno de los pasos, Ingest sabrá que los otros pasos funcionaron y solo reintentará este último hasta que funcione. Y así, ahora tenemos una campaña de goteo exitosa.

Pero, por supuesto, si alguna vez has hablado con algún gerente de producto, sabrás que puedes hacerlo mejor. Entonces, imagina que alguien ya se ha registrado e inmediatamente ha realizado la reserva. No tiene sentido enviarles exactamente el mismo correo electrónico que a alguien que, ya sabes, se está tomando su tiempo. Entonces, tal vez necesiten diferentes consejos, tal vez necesiten diferentes llamadas a la acción. Entonces, la campaña podría ser dinámica en función de las acciones del usuario. Así que construyámosla. Eliminemos estos dos últimos pasos porque eso es lo que nos gusta hacer, eliminar código. También podemos presumir de ello en Twitter.

Entonces, en otra parte de nuestra aplicación, cuando el usuario completa la reserva, se envía un evento como booking.created. Quiero decir, llamado booking.created al igual que user.signup. Ahora podemos utilizar este evento para determinar el curso de acción. Aquí estamos esperando cuatro días para ver si ocurre este evento. A continuación, utilizaremos el evento de reserva para determinar qué hacer a continuación. Si se realizó la reserva, recompensaremos a este usuario con consejos para usuarios avanzados, por ejemplo. Y, bueno, si necesitan cuatro días para realizar la reserva, tal vez necesiten, ya sabes, consejos básicos. Y, sabes, honestamente es muy divertido, ¿por qué detenerse ahí? Puedes volverte loco y crear muchos correos electrónicos con diferentes consejos. Y hablando de consejos, esto es solo la punta del iceberg. Esperaba risas aquí. No, estoy bromeando. Sabía que iba a haber silencio.

Entonces, estamos hablando aquí, ya sabes, de enviar correos electrónicos, pero en realidad no es solo una herramienta para enviar correos electrónicos. Hay numerosas herramientas, hay numerosos casos de uso que van más allá de una simple campaña de marketing. Puedes construir flujos de pago complejos, entrenamiento de LLM, orquestación de datos en varios pasos, y así sucesivamente. Básicamente, puedes pensar que si necesitas que ocurran varias cosas en respuesta a un evento, tal vez necesites una herramienta de confiabilidad. Por ejemplo, SoundCloud utiliza Ingest para agilizar la generación de videos dinámicos. O Faye utiliza Ingest con IA para resumir noticias masivas y conjuntos de datos. Y luego, la plataforma de envío de correos electrónicos que también utilizamos en este ejemplo utiliza Ingest para verificar los dominios de correo electrónico con flujos de trabajo sin servidor. Y funciona en cualquier nube. Es muy agnóstico en cuanto a lenguaje. Y aquí vimos mucho tipo y seguridad de tipo.

Pero además de TypeScript, también tenemos algunos SDK para Python, Go y también puedes invocar funciones escritas en un lenguaje en otro. Y también está el servidor de desarrollo local. Y en realidad, grabé un pequeño video para que lo veas. Sabes, estoy preocupado por las demostraciones en vivo. Así que pensé que simplemente lo grabaría para ahorrarte la frustración conmigo. De acuerdo. Así que construí una pequeña aplicación que, ya sabes, es una aplicación de reserva de restaurantes. Y primero, por supuesto, estamos iniciando Ingest, CLI, quiero decir, Ingest UI. Entonces, este es el servidor de desarrollo local. Y primero vamos a reservar una mesa y funcionará, ¿verdad? Entonces, puedes ver que se ejecuta la función, ves toda la información al respecto, la carga útil. Y luego también ves todas las noticias sobre la función, ¿verdad? Cuando se ejecuta, cuánto tiempo duerme, y así sucesivamente. Pero, ya sabes, eso es divertido. Pero, ¿qué sucede cuando realmente falla la solicitud? Entonces, tengo un botón que no funciona. Y luego ves que la función falló y vas allí. Y obtienes toda la información nuevamente. También obtienes el informe de errores aquí. Ves que, hmm, tal vez haya algo en tu code o en mi code. Obtengo información sobre dónde ocurrió eso. Pero lo más importante es que ves que los reintentos ya están en cola. Entonces, se reintentará incrementalmente, ya sabes, cada vez más después de intervalos más largos. Entonces, puedes volver a tu code y, bueno, puedo descubrir que simplemente no soy bueno para eso, no soy muy bueno programando. Y luego puedo volver a Ingest y reintentar, recuperar esa función. Y déjame volver a las diapositivas. Bueno, así que hablé mucho sobre Ingest. Pero en realidad, esta charla no trata sobre Ingest. Se trata de confiabilidad. Entonces, al construir una aplicación de producción del mundo real, la confiabilidad es realmente importante. No solo mantiene a tus usuarios felices, sino que también te hace a ti y a tu equipo más productivos y más relajados. Como desarrollador, no te ves tan abrumado por el mantenimiento y las operaciones. Pero lograr la confiabilidad es realmente difícil.

Y cualquiera que haya tenido que construir un sistema confiable a escala sabe la cantidad de iteración y trabajo previo que implica eso. Su confiabilidad es como seguridad. Es realmente difícil agregarla posteriormente y es una buena idea incluirla en las elecciones arquitectónicas desde el principio.

Entonces, en tiempos como estos, cuando los presupuestos de ingeniería y las plantillas se reducen, nosotros como ingenieros individuales necesitamos hacer más constantemente, hacer más con menos. Así que, al igual que probablemente estás externalizando tu lista de correo o el envío de correos electrónicos a proveedores de la nube, vale la pena preguntarse, ¿realmente quieres encargarte de gestionar tus propias colas? Y así, aquí, Matthew Drucker, el CTO de SoundCloud, piensa que no deberías hacerlo.

Y si ese es el caso, ya sabes, ¿por qué tanta gente sigue usando colas? Bueno, las colas han existido desde los años 90 y si, ya sabes, estamos acostumbrados a algo, se siente familiar y acogedor. Incluso si no es la solución más acogedora. Pero te mereces comodidad. Así que, volviendo al principio de la charla, realmente me gusta trabajar en proyectos en el sitio porque puedo enfocarme en las necesidades del usuario en lugar de todas las tareas desalentadoras como la confiabilidad. En 2024, todos merecemos diversión y alegría en nuestros trabajos diarios también. Así que, muchas gracias por estar aquí y vamos a pasar tiempo juntos, vamos a hablar y vamos a ser amigos. Gracias.

Entonces, si hay un fallo al enviar a Ingest, ¿hay algún tipo de alternativa o SDK para capturar o reintentar? Oh, sí. Entonces, ¿qué sucede cuando Ingest tiene una interrupción? Básicamente, en resumen, Ingest ofrece confiabilidad y seguridad. Hay numerosas herramientas diferentes en nuestra arquitectura que nos ayudan a cumplir esa promesa. Por ejemplo, nuestros ejecutores no comparten nada y nuestros almacenes de datos funcionan con replicación activa y conmutación por error maestro. Esto significa que si un motor de ejecución falla, entra en juego otro. Y nuestro motor de ejecución está separado de nuestra ingestión de eventos. Incluso si la ejecución falla, seguimos capturando todos los eventos. Y cuando eso se respalda, no perderás ningún dato.

Eso es increíble. Quiero decir, hablando al final sobre gestionar tus propias colas, sé que lo he hecho en el pasado. Y sé que, sí, soy mucho menos confiable que un servicio de terceros que está diseñado específicamente para esa confiabilidad. Así que, sí, absolutamente. Bien. Una pregunta. De acuerdo. ¿En qué momento sugerirías una separación de preocupaciones? ¿Debería un servidor orientado al usuario como el que describiste manejar tanto? Sí, quiero decir, lo que he visto es que a menudo un equipo comienza con Ingest para una tarea muy específica y de repente es muy fácil implementar Ingest en tu base de código. Y debido a eso, de repente están integrando Ingest en otras partes de la base de código para diferentes tareas. Entonces, para responder a la pregunta, ¿puede un servicio manejar todo? Sí, cada tarea tiene su propia cola. Así que tenemos algunos usuarios que ejecutan miles de colas y el mes pasado ejecutamos millones. Wow. Sí, no, parece que ya hay una separación de preocupaciones, ¿verdad? Sí, como múltiples tareas diferentes ahora. Sí. Oh, esa es una buena pregunta. De acuerdo. ¿Cómo trabajas con Ingest localmente? ¿Hay una opción local? Sí, esto es algo que todavía estamos discutiendo y siempre está en la mesa porque a menudo las personas preguntan sobre la opción de autohospedaje por preocupaciones de seguridad u otras. Entonces, dependiendo de la necesidad o el escenario específico, la respuesta puede ser sí, pero simplemente contáctanos en Discord.

Tenemos desarrollo local, sin embargo, porque a veces la gente también pregunta sobre eso. Así que, sí. De acuerdo. Creo que hubo una pregunta sobre el desarrollo local también. Así que, eso es más o menos— Y, básicamente, también el desarrollo local es gratuito, por lo que no necesitas tener una cuenta y también es de código abierto, así que simplemente ve y diviértete. De hecho, ayer mismo, Kensi Dot tuiteó que va a construir, como, un Ingest Light para poder usarlo en su curso. Así que, sí. Entonces, depende de tu caso de uso. Muy interesante. Muy interesante. Sigamos adelante.

¿Cuáles son los esfuerzos de infraestructura esperados para implementar el panel de control de la interfaz de usuario o hay algo ya implementado para eso? No. Entonces, el panel de control de la interfaz de usuario ya está disponible para ti. No es necesario. ¿Verdad? Así que, en realidad, estamos a punto de lanzar nuestro nuevo panel súper brillante con todas las métricas y observabilidad. Lamento no poder mostrarlo aquí. Pero, además del servidor de desarrollo local, también tienes, como, un panel adecuado, ya sabes, un panel de producción. Así que, también obtendrás toda la información allí. Fácil. Muy bien. Y esta es una pregunta que también tenía. Uh-huh. Que es, como, ¿cómo maneja ingest las fallas? Entonces, básicamente, supongo que es efectivamente, como, ¿qué sucede si una falla continúa durante 10 minutos? ¿Cuánto tiempo va a reintentar? Oh, lo reintentará. ¿Puedes configurarlo todo? Sí. Por lo tanto, puedes configurar tanto los incrementos como el número de reintentos. Y básicamente, ingest promete que los datos que se supone que se deben capturar se capturarán. Así que, sí. Por lo tanto, continuará. Supongo que hay una pequeña preocupación de que, si un servicio ha dejado de funcionar por algo y ahora has empaquetado un millón de eventos para luego volver a enviarlos. Sí, sí. No quieres enviarlos de vuelta. Puedes recuperar todo eso o también puedes iniciar sesión en ingest, ver, ya sabes, esos millones de eventos y decir, ya terminé con eso. Simplemente, detente, ya sabes.

Puedes detenerlo. Entonces, no. Lo que quieras hacer.

¿Y hay alguna forma de sacar esos data de ingest si solo quieres almacenarlos en otro lugar? Sí. Sí. Y volver a intentarlo más tarde. Sí. Definitivamente. Sí. Depende de lo que estés intentando hacer y cómo estés intentando hacerlo. Pero, sí. Sí. Los data son... no quiero entrar en detalles estrechos de cómo funciona ingest, pero básicamente, los data son tuyos. Entonces... Excelente.

Bueno, creo que eso es todo por ahora. Oh, gracias. Por favor, aplaudan nuevamente a Sylvia. Gracias. Y como siempre... Gracias. Gracias.