I was disappointed that this ended up being an ad for a SaaS instead of ways to build reliable backends without throwing money at the problem.
Video Summary and Transcription
Esta Charla explora el paradigma de las colas de mensajes para la ejecución confiable de backends. Destaca los beneficios de las colas de mensajes, como la entrega garantizada y la descarga de procesos de larga duración. Se discuten las desventajas de usar colas, incluyendo la complejidad de gestionar la infraestructura y las aplicaciones. Se presenta la solución de usar una capa de confiabilidad llamada Ingest, que permite tareas en segundo plano sin bloqueo y proporciona un panel de control para monitorear y gestionar trabajos. La Charla también enfatiza la importancia de la confiabilidad en la construcción de sistemas de software e introduce el alcance y la funcionalidad en expansión de Ingest.
Hola a todos. Bienvenidos a mi charla sobre confiabilidad, backend y ejecución. Discutiré el paradigma que facilita la vida. Ahora estamos viviendo en una constante nostalgia de los años 90. Los años 90 nos trajeron muchas cosas geniales, pero hay una cosa de la que podríamos despedirnos: las colas. Las colas de mensajes son una forma de comunicación asincrónica entre servicios. Permiten una entrega garantizada y la descarga de procesos de larga duración.
Hola a todos. Bienvenidos a mi charla donde, durante los próximos 20 minutos, hablaré sobre confiabilidad, backend y ejecución. Solo una breve introducción. Mi nombre es Sylvia Vargas. Soy de Polonia. Me encantan los pierogi y anteriormente trabajé en StackBlitz. Ahora soy líder de relaciones con desarrolladores en Ingest. Esta charla trata sobre el paradigma que facilita la vida. Pero antes de hablar de lo bueno, hablemos de lo malo. Ahora estamos viviendo en una constante nostalgia de los años 90. Y, por supuesto, esto no es sorprendente. Los años 90 nos trajeron muchas cosas diferentes, cosas geniales que todavía están con nosotros. Sin embargo, hay una cosa de la que posiblemente podríamos despedirnos. Y estas son las colas. Así que veamos qué son las colas de mensajes. Una cola de mensajes es una forma de comunicación asincrónica entre servicios utilizando una arquitectura de microservicios. Los mensajes se almacenan en la cola hasta que se procesan y se eliminan. Cada mensaje es procesado solo una vez por un único consumidor. Pero aquí necesito interrumpir porque en realidad, varios trabajadores pueden consumir mensajes de una cola. Para preservar el orden de las tareas, deberán ejecutarse en serie. Pero volviendo a la definición ahora. Y las colas de mensajes se pueden usar para desacoplar el procesamiento pesado para almacenar o agrupar trabajos y suavizar las cargas de trabajo pico. Entonces puedes pensar en que una vez que agregas algo a la cola, llegará a su destino uno por uno. La entrega está garantizada. Y lo que sucede en la cola no afecta otras partes de la infraestructura. Y las colas pueden ser realmente masivas. Así que recapitulemos. Con las colas, obtienes entrega garantizada porque sabes que una vez que algo se agrega a la cola, solo la dejará una vez que se procese. Y las colas permiten a los desarrolladores descargar procesos de larga duración al fondo para que tu aplicación no se atasque. Usarías colas para tareas intensivas de datos.
2. Drawbacks of Using Queues
Short description:
Y otra ventaja de las colas es la escalabilidad horizontal. Sin embargo, hay inconvenientes en el uso de colas. Construir infraestructura adicional y gestionar aplicaciones complejas puede ser mucho trabajo. En tiempos de presupuestos y recursos limitados, vale la pena considerar si gestionar colas es la elección correcta. En cambio, la ejecución duradera nos permite definir la lógica del flujo de trabajo en el código de nuestra aplicación y garantiza una ejecución confiable.
procesos o al integrarse con sistemas externos. Y otra ventaja es la escalabilidad horizontal porque se pueden procesar varios mensajes en paralelo. A medida que aumenta la carga de trabajo, las aplicaciones múltiples pueden manejar un alto rendimiento y seguir siendo confiables. Sin embargo, hay un pero. Así que veamos este comentario de Reddit. Las colas son geniales en procesos intensivos de datos, como dije, que no necesitan ejecutarse en el hilo principal porque se ejecutan de forma asincrónica. Las tareas se procesan en segundo plano y la aplicación sigue siendo receptiva. Sin embargo, hay algunos inconvenientes en las colas, que este usuario de Reddit menciona delicadamente en esta cita. Una vez que tomas algo de la cola, el resto depende de ti. Y el servicio de encolado ya no se preocupa. Entonces, ¿qué significa eso? Veamos eso. Las colas son geniales cuando tu aplicación es simple. Cuando crece en complejidad o si es distribuida, de repente necesitas preocuparte por toda una serie de infraestructura adicional que necesitas construir. Y serás tú quien tenga que construirla. Por ejemplo, deberás construir concurrency porque quieres poder controlar cuántos pasos se ejecutan al mismo tiempo. O, por ejemplo, debouncing porque todos sabemos lo costoso que es cuando las funciones se ejecutan varias veces. O persistencia y gestión de estado porque ahora que tienes una aplicación distribuida o compleja, debes compartir el estado entre diferentes funciones y colas. Luego también está el manejo de errores porque ¿qué pasa si hipotéticamente un proveedor de servicios tiene una interrupción? Deberás incluir reintentos y también fallos. Quiero decir, reintentos para fallos y también tiempos de espera. Y en ese caso, también necesitas herramientas de recuperación para comprender y procesar los errores y eventos fallidos. Esto ya suena como mucho trabajo y ni siquiera es una lista exhaustiva. Así que no tienes que escucharme a mí en eso. En momentos como este, cuando los presupuestos de ingeniería y las plantillas se reducen, nosotros como desarrolladores e ingenieros individuales debemos hacer más con menos. Entonces, realmente vale la pena preguntarse en este momento, ¿realmente quieres estar en el negocio de gestionar y operar tus propias colas? Bueno, Matthew Druker, el CEO de SoundCloud, no cree que debamos hacerlo. Entonces, si esto es ahora un conocimiento común, ¿por qué la gente sigue usando colas? Bueno, estamos acostumbrados a algo. Se siente familiar y acogedor incluso si no es la solución más acogedora. Puedes hacer que todo funcione con el esfuerzo suficiente. Afortunadamente, hay una mejor solución que se basa en el concepto de colas de mensajes. Entonces, en lugar de separar nuestra infraestructura, como las colas, de nuestro código, ¿qué tal si pudiéramos definir nuestra lógica de flujo de trabajo puramente en nuestro código de aplicación y asegurarnos de que se ejecute de manera confiable? Esto es lo que nos ofrece la ejecución duradera. La ejecución duradera es, como su nombre indica, duradera. Garantiza que nuestro código se ejecute.
3. Additional Functionalities and Real-World Example
Short description:
Esta parte explica las funcionalidades adicionales proporcionadas por el sistema. También presenta un ejemplo del mundo real de cómo construir un flujo de registro utilizando servicios de terceros, enfatizando la simplicidad y facilidad que ofrece a los desarrolladores.
se completará, incluso si hay fallos en los mensajes en el camino. Por lo tanto, esta parte es la misma que las colas de mensajes. Sin embargo, a diferencia de las colas de mensajes, también obtienes lógica retrospectiva, manejo de errores, o persistencia de estado, que viene integrado. No tienes que construirlo. Se te proporciona.
La otra parte es el control de flujo, que es todo lo demás que se necesita para que puedas ejecutar tus funciones de manera confiable, como concurrency (concurrencia), debouncing, priorización de tareas, manejo de fallos o herramientas de recuperación. Suficiente teoría. Veamos un ejemplo del mundo real. Trabajas en una nueva startup de reservas de restaurantes muy popular. Tu jefe te pregunta cuánto tiempo te llevará construir un flujo de registro. Entonces recibes una lista de requisitos del gerente de productos. Lo miras con un café con leche helado en la mano. Estás completamente tranquilo. Veamos. Necesitas autenticar de forma segura al usuario. Necesitas agregar al usuario a una database (base de datos). Necesitas agregar al usuario a la lista de correo. Y finalmente enviar un correo electrónico de bienvenida. Afortunadamente, construir esto es mucho más fácil hoy en día de lo que hubiera sido hace cinco años. Porque puedes usar Clerk para la autenticación, SupaBase para la base de datos, MailChimp para la lista de correo y Resend para
4. Challenges of Distributed Applications
Short description:
Construir aplicaciones utilizando servicios de terceros es inteligente y facilita la vida. Sin embargo, hay un inconveniente. A veces, los servicios pueden ser lentos, lo que causa código bloqueante y ralentiza la API. Esto afecta la experiencia del usuario. Gestionar reintentos, registrar errores e implementar un sistema de recuperación añade complejidad y aumenta el tiempo de desarrollo.
email. De acuerdo. Trabajo hecho. Puedes dar un gran sorbo a tu café con leche helado y volver a jugar Wordle o leer uno de esos miles de hilos en Twitter. Entonces, aquí está el code. Y crearías un usuario en la database. Enviarías un correo electrónico de bienvenida. Y agregarías al usuario como miembro de una lista de correo. Bueno, esto parece muy simple. Y nos gusta lo simple. ¿Verdad? Somos perezosos como desarrolladores. Construir aplicaciones utilizando servicios de terceros es inteligente y facilita la vida. Así que nos gusta lo fácil. Pero, ¿dónde está el problema? ¿Termina aquí mi presentación? Bueno, no. Hay un inconveniente. Porque ahora hemos creado una aplicación distribuida en la que no tenemos control sobre gran parte de la infraestructura en la que confiamos. Por ejemplo, a veces los servicios pueden ser lentos. Enviar un correo electrónico o incluso en un buen día puede llevar medio segundo. Así que ahora tenemos un problema. Tenemos código bloqueante en el camino crítico de nuestra solicitud. Como resultado, estamos haciendo que nuestra API sea más lenta. En otras palabras, tu usuario está perdiendo tiempo. La experiencia del usuario no debería verse afectada debido a los requisitos del negocio. Entonces, ¿cómo lo estamos haciendo hasta ahora? ¿Es rápido? Bueno, no. Pero, ¿es confiable? Tampoco. Imagina que mientras estás agregando un usuario a una lista de correo, un servicio se cae. Necesitas gestionar los reintentos. Uno, dos, tres, cuatro reintentos. ¿Y si algo falla permanentemente? Necesitas registrar estos errores en un servicio de registro. Y también necesitas idear un sistema de recuperación. Por lo tanto, la estimación para construir esta característica muy simple ahora es de semanas en lugar de días. Necesitas configurar la infraestructura y los procesos.
5. Solving Partial Failures with Ingest
Short description:
Las fallas parciales son malas. Ignorar errores, mostrar errores a los usuarios o hacer que los usuarios vuelvan a intentar registrarse puede llevar a la pérdida de clientes y entradas duplicadas. Esto resulta en una aplicación lenta y frustrante. Para resolver esto, podemos mover tareas no bloqueantes a trabajos en segundo plano utilizando Ingest. Ingest es una capa de confiabilidad que te permite definir y ejecutar funciones de forma asíncrona. Proporciona un panel de control para monitorear y administrar trabajos.
Además, las fallas parciales son realmente malas. Entonces, imagina esto. Has agregado al usuario a la database, pero no le has enviado un correo electrónico. Ahora tenemos tres opciones. Primero, puedes ignorar el error, lo que significa que el usuario no está en la lista de correo. Segundo, aún peor, mostramos al usuario el error, lo que llevará a la pérdida de un cliente. Y tercero, el peor caso de todos, el usuario volverá a intentar registrarse. Veamos eso. Así que supongamos que el usuario recibe el error e intenta registrarse nuevamente. Pero ahora, el usuario que se crea generará un error porque hay un duplicado. Bueno, buena suerte recuperándote de eso. Así que este es el lío en el que estamos. Y la aplicación tarda una eternidad en funcionar. Me lleva una eternidad construirla. Estaré molesto en mi trabajo porque de repente tengo que lidiar con la acumulación de soporte. Aún no estamos lidiando con las fallas persistentes. Y todos están descontentos. Mi jefe está descontento. Estoy estresado. No puedo dormir. Pero hay una solución. Podemos hacer que nuestro code sea más rápido y confiable. Entonces, movamos las tareas no bloqueantes a trabajos en segundo plano. Primero, agregaremos Ingest al proyecto. Ingest es una capa de confiabilidad para tu aplicación. Entonces, con Ingest, defines funciones o flujos de trabajo utilizando su SDK directamente en tu base de code, y luego los sirves a través de un punto de conexión HTTP en tu aplicación. Entonces, Ingest se encarga de ejecutar funciones de forma confiable de manera asíncrona. También hay un panel de control donde puedes monitorear,
6. Using Ingest for Reliable Function Execution
Short description:
Agregamos una capa de confiabilidad llamada Ingest. Las funciones se envuelven en Ingest.create para ejecutarse cuando se activa un evento. Se utiliza el mismo nombre de evento para varias funciones que se ejecutan simultáneamente, conocido como fan out. En lugar de invocar las funciones directamente, desencadenamos eventos en Ingest a través de un punto de conexión HTTP. Ingest ejecuta las funciones y proporciona notificaciones en el panel de control. Ingest vuelve a intentar automáticamente las funciones fallidas hasta que tengan éxito.
debug, y administra tus trabajos. Todo es visual. Entonces, así es como se ve tu aplicación ahora. Vamos a agregar una capa de confiabilidad que es Ingest. Primero, vamos a envolver esta función en la función Ingest.create. Como puedes ver, estamos proporcionando un nombre de evento. Más tarde, cuando el usuario se registre, desencadenaremos un evento con este nombre. Lo verás en un segundo. Esto le dirá a Ingest que ejecute la función. Así es como se vería en code. Estamos creando la función. Proporcionamos el nombre del evento e invocamos nuestro código existente de MailChimp code de antes. Y ahora haremos lo mismo para la otra función. Como puedes ver, estamos usando el mismo nombre de evento. Esto se debe a que queremos que estas dos funciones se ejecuten al mismo tiempo. Entonces, cuando el usuario se registre, queremos que estas dos funciones se ejecuten. Este patrón se llama comúnmente fan out. Entonces, ahora cuando el usuario haga clic en el botón, enviaremos un evento a Ingest. Así es como se ve en el code. En lugar de invocar estas funciones directamente, desencadenaremos un evento en Ingest. Como mencioné antes, exponemos funciones a Ingest a través de un punto de conexión HTTP. Ingest utiliza este punto de conexión para ejecutar las funciones específicas cuando se activa un evento. Este es el punto de conexión. Ingest lo utilizará para descargar las definiciones de las funciones y luego ejecutarlas. Y aquí está el flujo completo. Entonces, Ingest llama a las funciones correctas en el momento preciso que deseas. Y luego en el panel de control, recibirás una notificación de que se ha desencadenado un evento, que a su vez llamó a dos funciones. Así que vemos que se completaron y cuándo. Todo esto se ve bien. Pero, ¿qué sucede cuando hay un fallo? Bueno, veamos eso. Ingest invoca la función y digamos que falla con un error code. Entonces, lo volverá a intentar una y otra vez hasta que finalmente tenga éxito. No necesitas
7. Explorando Funcionalidades Adicionales de Ingest
Short description:
Puedes solucionar fácilmente errores con la herramienta de consola de Ingest y recuperarte volviendo a activar eventos fallidos. Ingest permite programar tareas en el futuro y orquestar procesos de múltiples pasos. Aumenta la retención de usuarios enviando campañas de correo electrónico de activación.
preocuparte por eso. Además, obtendrás un registro detallado de lo que sucedió. Sé que es difícil de creer, pero a veces los errores persisten no debido a la falta de servicio, sino porque hay errores en nuestro code. Sé que es difícil de creer. Pero en esos casos, en realidad puedes depurar fácilmente con la herramienta de consola de Ingest y una vez que hayas corregido tu función, puedes recuperarte volviendo a activar eventos fallidos. Entonces, ¿cómo lo estamos haciendo ahora? Queríamos hacer que nuestra aplicación sea más rápida, así que movimos las tareas no bloqueantes del camino crítico del usuario a trabajos en segundo plano. Pero además, obtuvimos confiabilidad como una buena adición. Así que ahora tenemos acceso a esta gran infraestructura. Entonces, veamos qué más podemos hacer con ella. Así es como se ve nuestra aplicación en este momento. Aún no te lo había dicho, pero Ingest en realidad te permite programar tareas en el futuro y también orquestar procesos de múltiples pasos. Así que veamos la función de enviar correo electrónico. Aquí, simplemente estamos enviando un correo de bienvenida pero siempre es bueno aumentar la retención de usuarios. Podríamos enviarles una campaña de correo electrónico de activación durante la primera semana. ¿Cómo lo haríamos? Así que primero creemos una función de Ingest,
8. Building a Drip Campaign with Ingest
Short description:
Podemos usar los pasos de Ingest para construir una campaña de goteo con progresión secuencial. Ingest se encarga de la programación para pausar la ejecución de la función. El último paso es el correo electrónico final con consejos. La campaña puede ser dinámica según las acciones del usuario. Usaremos el evento de reserva para determinar el curso de acción.
que reaccionará al mismo evento. Hasta ahora, hemos estado hablando del patrón de propagación, donde tienes múltiples funciones que se activan en el mismo evento. Sin embargo, muchas tareas requieren una progresión secuencial. Aquí estamos construyendo una campaña de goteo, por lo que es conveniente que podamos expresar toda la línea de tiempo como un code procedural. Entonces, usaremos los pasos de Ingest dentro de esta función. Estamos aquí, como puedes ver, estamos usando un paso de Ingest que se ejecuta. De esta manera, el code se volverá a intentar automáticamente si falla. Pero el code que se ejecuta correctamente nunca se volverá a intentar. Lo veremos en acción en un momento. Y primero, estamos enviando un correo electrónico de bienvenida. Esta es la misma parte, la misma parte que hicimos antes. Luego, Ingest pausará la ejecución de esta función durante cuatro días. Para esto, estamos usando step.sleep. Desde la perspectiva de un programador, se ve similar a poner un tiempo de espera, pero en realidad, en segundo plano, Ingest se encarga de la programación por ti. Entonces, esto significa que tu función serverless no se ejecuta durante cuatro días. Entonces, no tienes que vender tu riñón para pagar tu factura de AWS. Y el último paso es el correo electrónico final con tips. Si hay un fallo en uno de los pasos, Ingest sabrá que los otros pasos funcionaron y solo volverá a intentar ese paso hasta que funcione. Entonces, ahora hemos construido una exitosa campaña de goteo y nos merecemos un aplauso. Pero en realidad podemos hacerlo mejor. Imagina que alguien ya se ha registrado e inmediatamente ha realizado una reserva. No tendría sentido que recibieran el mismo correo electrónico que alguien que no finalizó una reserva. Tal vez necesiten diferentes tipos de tips o diferentes llamadas a la acción. La campaña podría ser realmente dinámica según las acciones del usuario. Entonces, hagámoslo. Eliminemos los dos últimos pasos. En otro lugar de tu aplicación, cuando el usuario completa una reserva, se envía un evento llamado booking.created, al igual que user.signup. Entonces, ahora usamos este evento para determinar el curso de acción. Aquí, esperamos cuatro días para ver si este evento incluso sucederá. A continuación, usaremos un evento de reserva para determinar el curso de acción. Si se realizó la reserva, recompensaremos
9. Expanding the Scope of Ingest
Short description:
Si se realizó la reserva, recompensaremos a esta persona con consejos para usuarios avanzados. Hay numerosos casos de uso que van más allá de las campañas de marketing. Puedes construir flujos de pago complejos, LLM, encadenamiento de comandos o transformación de datos en múltiples pasos. Ingest también es independiente del framework y del lenguaje.
Recompensaremos a esta persona con consejos para usuarios avanzados. Y, bueno, si necesitan cuatro días para hacer una reserva, necesitarán algunos consejos básicos. Y esto es realmente divertido, por eso me detuve ahí. Podrías volverte loco y crear muchos correos electrónicos con muchos consejos. Y hablando de consejos, todo esto es solo la punta del iceberg. Aquí estamos hablando de enviar correos electrónicos. Pero Ingest no es solo una herramienta para enviar correos electrónicos. Hay numerosos casos de uso que van más allá de las campañas de marketing. Puedes construir flujos de pago complejos, LLM, encadenamiento de comandos o transformación de datos en múltiples pasos. Siempre que necesites que ocurran muchas cosas en respuesta a un evento dado, puedes considerar Ingest. Por ejemplo, SoundCloud utiliza Ingest para agilizar la generación de videos dinámicos. Y luego, AOMNI ha utilizado Ingest para construir ventas impulsadas por IA utilizando LLM sin servidor. Resend, la plataforma de envío de correos electrónicos que en realidad utilizamos en el ejemplo anterior, utiliza Ingest para verificar los dominios de correo electrónico con flujos de trabajo sin servidor. Simplemente funciona en cualquier nube, Vercel, Netlify, tú lo nombras. Además, también puedes integrar, puedes migrar de una nube a otra sin tiempo de inactividad. Aquí tienes una publicación de blog,
10. Expanding SDKs and Importance of Reliability
Short description:
Recientemente agregamos soporte para BAN y ASTRA. Nuestros SDK están disponibles para TypeScript, Python y Go, con planes de agregar más. Combina y combina los SDK en tus flujos de trabajo e invoca funciones escritas en un lenguaje desde otro. También tenemos un servidor de desarrollo local para facilitar las pruebas. Construir sistemas confiables es crucial para la satisfacción del usuario y la productividad del equipo. Ingest sirve como una capa de confiabilidad, pero tarde o temprano necesitarás una solución. La confiabilidad debe considerarse desde el principio en las elecciones arquitectónicas. Gracias.
si tienes curiosidad. Ingest también es agnóstico de framework. Aquí hay solo algunos de ellos. Pero también hemos agregado recientemente soporte para BAN y ASTRA, por ejemplo. Y finalmente, también es agnóstico de lenguaje. En este ejemplo, vimos mucho TypeScript y type safety. Pero además de TypeScript, también tenemos SDK para Python y Go. También estamos buscando agregar más. Y por cierto, nuestra especificación de SDK es de código abierto y estamos invitando contribuciones. Y dato curioso, también puedes combinar y combinar todos esos SDK en tus flujos de trabajo e invocar funciones escritas en un lenguaje en otro. También hay, finalmente, un servidor de desarrollo local, que no requiere que inicies sesión, por lo que puedes verlo ahora mismo. Pero, sabes, aquí hablé mucho sobre Ingest. Pero esta charla no se trata solo de Ingest. Al construir aplicaciones de producción del mundo real, la confiabilidad es realmente importante. No solo mantiene a tus usuarios felices, sino que también hace que tu equipo sea más productivo. Y tú como desarrollador te ves menos obstaculizado por el mantenimiento y las operaciones. Lograr la confiabilidad es difícil. Cada ingeniero que alguna vez ha tenido que construir un sistema confiable a gran escala conoce la cantidad de iteración e infraestructura que implica. En este ejemplo, usamos Ingest como la capa de confiabilidad. Pero ya sea que uses soluciones de terceros o no, tarde o temprano terminarás necesitando una. La confiabilidad es como la security. Es difícil agregarla después. Entonces, incorporarla en tus elecciones arquitectónicas desde el principio generalmente es una buena idea. Y sí, gracias a todos. Si quieres comunicarte conmigo o ser amigos, aquí es donde puedes encontrarme. Gracias.
Vite is a next-generation build tool that leverages native ES modules for improved performance. It eliminates the need for bundling and improves hot module replacement. Vite provides an opinionated default configuration while still allowing advanced customization through plugins. It is framework agnostic and can be used for React and other applications. Vite is being adopted by Next.js and Create React App, and integration with Nuxt 3 offers significant speed improvements.
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
BUN is a modern all-in-one JavaScript runtime environment that achieves new levels of performance. It includes BUN dev, a fast front-end dev server, BUN install, a speedy package manager, and BUN run, a fast package runner. BUN supports JSX, has optimized React server-side rendering, and offers hot module reloading on the server. The priorities for BUN include stability, node compatibility, documentation improvement, missing features in BUN install, AST plugin API, native Windows support, Bundler and Minifier optimization, and easier deployment to production. BUN's AST plugin API allows for bundle-time JavaScript execution and embedding code, potentially inspiring new frameworks.
The Talk discusses TurboPack, a successor to Webpack, aiming to create a framework-independent, flexible, and extensible tool for the open-source community. It addresses performance challenges by integrating SWC into Next.js. The challenges with Next.js and Webpack include orchestration issues, backward compatibility constraints, and cache invalidation problems. TurboEngine and TurboPack provide constant performance in incremental builds, leveraging Rust's predictable performance and parallelism. The Talk also covers topics like dependency tracking, task graphs, cache invalidation, lazy asset graphs, and the integration of TurboPack with Next.js. The future plans involve reconfiguring Webpack and TurboEngine, moving computations to the cloud, providing insights into builds, and facilitating migration and integration with JavaScript projects.
Tobias Koppers introduces TurboPack and TurboEngine, addressing the limitations of Webpack. He demonstrates live coding to showcase the optimization of cache validation and build efficiency. The talk covers adding logging and memorization, optimizing execution and tracking dependencies, implementing invalidation and watcher, and storing and deleting invalidators. It also discusses incremental compilation, integration with other monorepo tools, error display, and the possibility of a plugin system for Toolpag. Lastly, the comparison with Bunn's Builder is mentioned.
Welcome to vidBuild, a tool that optimizes your application for production by offering fast hodgemodule replacement and support for various technologies. The build process in vidBuild involves optimizing and minifying assets, bundling JS and CSS, and generating chunks for dynamic imports. The pipeline in vidBuild includes plugins for alias, resolution, CSS modules, and asset handling. Vid is a complete build tool with a flexible plugin system and support from a vibrant community. Vite's plugin API is compatible with Rollup, and Vite aims for simplicity while pushing complexity to the plugin system.
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
WorkshopFree
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres? En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
Prisma es un ORM de código abierto para Node.js y TypeScript. En esta masterclass, aprenderás los flujos de trabajo fundamentales de Prisma para modelar datos, realizar migraciones de base de datos y consultar la base de datos para leer y escribir datos. También aprenderás cómo Prisma se integra en tu stack de aplicaciones, construyendo una API REST y una API GraphQL desde cero utilizando SQLite como base de datos. Tabla de contenidos: - Configuración de Prisma, modelado de datos y migraciones- Explorando Prisma Client para consultar la base de datos- Construyendo rutas de API REST con Express- Construyendo una API GraphQL con Apollo Server
Construyendo un backend serverless nativo de GraphQL con Fauna
WorkshopFree
2 authors
¡Bienvenido a Fauna! Este masterclass ayuda a los desarrolladores de GraphQL a construir aplicaciones de alto rendimiento con Fauna que se escalan a cualquier tamaño de base de usuarios. Comienzas con lo básico, utilizando solo el playground de GraphQL en el panel de Fauna, luego construyes una aplicación completa de pila completa con Next.js, agregando funcionalidad a medida que avanzas.
En la primera sección, Comenzando con Fauna, aprendes cómo Fauna crea automáticamente consultas, mutaciones y otros recursos basados en tu esquema de GraphQL. Aprendes cómo realizar tareas comunes con GraphQL, cómo usar el lenguaje de consulta de Fauna (FQL) para realizar tareas más avanzadas.
En la segunda sección, Construyendo con Fauna, aprendes cómo Fauna crea automáticamente consultas, mutaciones y otros recursos basados en tu esquema de GraphQL. Aprendes cómo realizar tareas comunes con GraphQL, cómo usar el lenguaje de consulta de Fauna (FQL) para realizar tareas más avanzadas.
Este masterclass explorará cómo construir APIs GraphQL respaldadas por Neo4j, una base de datos de grafos nativa. La biblioteca Neo4j GraphQL permite a los desarrolladores diseñar e implementar rápidamente APIs GraphQL completamente funcionales sin escribir ningún resolvedor. Este masterclass mostrará cómo utilizar la biblioteca Neo4j GraphQL para construir una API GraphQL en Node.js, incluyendo la adición de lógica personalizada y reglas de autorización.
Tabla de contenidos: - Visión general de GraphQL y construcción de APIs GraphQL - Construcción de APIs GraphQL en Node.js respaldadas por una base de datos de grafos nativa utilizando la biblioteca Neo4j GraphQL - Adición de lógica personalizada a nuestra API GraphQL utilizando la directiva de esquema @cypher y resolvedores personalizados - Adición de reglas de autenticación y autorización a nuestra API GraphQL
Comments