Lleva Node.js a tu navegador con WebContainers

Rate this content
Bookmark

En esta charla, me encantaría informar e inspirar a la comunidad para superar las limitaciones del desarrollo web ejecutando Node.js dentro del navegador. Cubriré cómo y por qué desarrollamos WebContainers, cuáles fueron y son nuestros obstáculos y limitaciones, cómo hemos trabajado con la comunidad para mejorar la tecnología y qué se ha habilitado y construido con WebContainers.

21 min
17 Apr, 2023

Video Summary and Transcription

Esta charla discute cómo llevar Node.js al navegador utilizando contenedores web. Cubre la historia de Node.js y de Internet en la década de 2000, las posibilidades de Node.js en el navegador y los enfoques para lograrlo. También explora el viaje y crecimiento de Stackbits, la innovación en el diseño de contenedores web y la funcionalidad de los contenedores web. La charla enfatiza la importancia del código abierto y la colaboración en la mejora del ecosistema web.

Available in English

1. Introducción a NodeJS en el navegador

Short description:

Bienvenidos a mi charla sobre cómo llevar NodeJS a tu navegador con contenedores web. Hablaremos sobre la historia de Node, los navegadores y los contenedores web. Los contenedores web de StackBits permiten ejecutar aplicaciones de NodeJS en el navegador. Esta es la primera discusión pública sobre este tema. Soy Silvia Vargas, una desarrolladora de front-end y relaciones con desarrolladores en StackBits. El plan abarca desde principios de los años 2000, llevando Node.js al navegador en los años 2020 y el presente y futuro. Echa un vistazo a node.neo, un entorno de pruebas de Node.js desechable impulsado por contenedores web. Comencemos retrocediendo a principios de los años 2000.

Hola Congreso de NodeJS, bienvenidos a mi charla sobre cómo llevar NodeJS a tu navegador con contenedores web. Hablaremos sobre la historia de Node, sobre los navegadores y finalmente sobre los contenedores web.

Los contenedores web son una tecnología de StackBits que te permite ejecutar aplicaciones de NodeJS dentro de tu navegador. Esta es realmente la primera vez que estamos hablando de esto en público, así que gracias por tenerme aquí.

Me llamo Silvia Vargas y soy una desarrolladora de front-end, pero también me encargo de las relaciones con los desarrolladores en StackBits.

Este es el plan para los próximos 20 minutos. Primero hablaremos sobre principios de los años 2000 y los intentos de sacar a JavaScript del navegador. Luego retrocederemos a los años 2020, donde hablaremos sobre cómo llevar Node.js al navegador. Y finalmente, echaremos un vistazo al presente y al futuro. Como verán, esta charla realmente comienza y termina con los navegadores, así que verán muchos de ellos en esta charla.

Si eres una persona a la que le gusta probar las cosas de inmediato, ve a echar un vistazo a node.neo, que es un entorno de pruebas de Node.js desechable impulsado por contenedores web. Mientras tanto, mientras experimentas el futuro, retrocederemos en el tiempo a principios de los años 2000. ¿Estás listo? Bien, entonces hablemos sobre la historia de Node.js.

2. Node.js Historia e Internet en los primeros años 2000

Short description:

Node.js, creado por Ryan Dahl en 2009, llevó JavaScript del lado del servidor a la corriente principal. Fue creado para manejar una gran cantidad de solicitudes simultáneas y fue posible gracias al lanzamiento de Chrome con el motor JavaScript V8 en 2008. V8 compila JavaScript a código de máquina para una ejecución más rápida. Node.js se convirtió en un marco del lado del servidor basado en eventos que podía manejar operaciones de E/S de manera no bloqueante. Esta idea fue presentada por Ryan Dahl en JsConf en 2009. En los primeros años 2000, cuando Internet era menos potente, Ryan Dahl estaba emocionado con la barra de progreso al cargar archivos.

Node.js fue creado por Ryan Dahl en 2009. Es importante tener en cuenta que JavaScript fue creado para ejecutarse dentro del navegador. En una de sus charlas, Ryan explicó cómo estaba buscando una forma de construir una aplicación de red que pudiera manejar una gran cantidad de solicitudes simultáneas. Antes de Node.js, hubo algunos intentos de ejecutar JavaScript fuera del navegador. Por ejemplo, uno de esos intentos fue Rhino. Pero nunca lograron llevar JavaScript del lado del servidor a la corriente principal. Node.js cambió eso. Veamos cómo sucedió.

En 2008, se lanzó Chrome con V8. V8 es un motor JavaScript. Es un proyecto de código abierto diseñado para ejecutar código JavaScript lo más rápido posible mediante la compilación JIT, just-in-time. Eso significa que JavaScript se compila a código de máquina y no se interpreta. Aquí está la publicación del blog de anuncio de 2008. No la leeremos en su totalidad, no te preocupes. Pero echemos un vistazo a un fragmento. Así que a nadie le gustan las citas largas, así que vamos a desglosarla. Aquí hay algunas palabras proféticas. A medida que las aplicaciones web crecen, creemos que este conjunto será representativo de cómo los desarrolladores web escriben código JavaScript. Chrome realmente cambió la forma en que se escribe JavaScript, pero también dónde se escribe. Y ahora la segunda parte de la cita. En la segunda parte, mencionan su conjunto de pruebas asombroso que consta de cinco aplicaciones JS promedio. Un total de 11,000 líneas de código, 11,000. Te dejo con este número. En este contexto, Ryan Dahl extrae el código fuente de V8 y pasa seis meses creando Node.js. Node.js fue diseñado para ser un marco del lado del servidor basado en eventos que pudiera manejar operaciones de E/S de manera no bloqueante. Ahora JavaScript realmente se puede ejecutar en todas partes. Y aquí hay una charla de 2009, JsConf, donde Ryan Dahl presentó esta idea.

Para comprender mejor nuestros problemas, los problemas a los que nos enfrentamos hoy, echemos un vistazo a la historia una vez más, o por última vez. ¿Cómo era Internet en esos días, a principios de los años 2000? En ese entonces, los navegadores no eran demasiado potentes. Por ejemplo, en una charla, Ryan Dahl menciona lo emocionado que estaba con la barra de progreso al cargar archivos.

3. Posibilidades de Node.js en el navegador

Short description:

En los primeros años 2000, los navegadores eran menos potentes, con solo 5 páginas promedio que sumaban un total de 11,000 líneas de código. Ahora, con el avance de la tecnología, los navegadores son capaces de computación en el borde, colaboración en tiempo real e IA. Traer Node.js al navegador abre posibilidades para la educación, documentación, pruebas, herramientas del lado del cliente, empleo y experimentación. Sin embargo, es importante tener en cuenta que Node.js está diseñado para API del lado del servidor.

Por ejemplo, en una charla, Rayon Daal menciona lo emocionado que estaba con la barra de progreso al cargar archivos. Solo para recordar, así es como se veía la barra de progreso. Quiero decir. Avancemos 15 años y vemos que los navegadores han crecido en potencia. Ahora, veamos la comparación. En los años 2000, 5 páginas promedio eran solo 11,000 líneas de código en total. Ahora, cuando ejecutas una aplicación de React Create, solo eso genera 30,000 líneas.

En 2005, se lanzaron Google Maps y Gmail. Ahora estamos hablando de computación en el borde, colaboración en tiempo real e IA. En ese entonces, los tres principales sitios web en 2005 eran Wikipedia, Flickr e iTunes. O en 2008. Ahora son Google, Facebook, TikTok. Si observas esos tres, en realidad, esas parejas son bastante similares, pero solo en términos de cómo se usan y no realmente la tecnología. Y en los años 2000, debemos recordar que eso fue antes de ES5, mientras que ahora estamos en muchas iteraciones de ECMAScript por delante. Tenemos los websockets, los service workers, y más. Dado lo poderosos que son los navegadores en la actualidad, tal vez realmente podríamos ejecutar JavaScript, incluido Node.js, en todas partes. Así que hablemos de cómo llevar Node.js a los navegadores.

El hecho de que puedas hacer algo no significa que debas hacerlo. Así que veamos qué se podría habilitar con Node.js ejecutándose en el navegador. Por ejemplo, hay un caso de uso en la educación. Desde cursos, blogs, hasta demos, tu audiencia podría experimentar lo que les estás enseñando directamente en el sitio web. Documentación, mostrar siempre es mejor que contar. Pruebas, crear reproducciones. Herramientas del lado del cliente, como empaquetadores, ejecutores de tareas, y generadores de código. Empleo, como plataformas de entrevistas o de incorporación. Y finalmente, experimentación. Nosotros mismos no sabemos cómo puedes aprovechar realmente los Contenedores Web al máximo. Ya veremos.

Así que ahora todo suena genial, pero, bueno, hay un pero. Node.js está diseñado para trabajar con API del lado del servidor, como sistemas de archivos, sockets de red y servidores HTTP.

4. Enfoques para llevar Node.js a los navegadores

Short description:

Una gran parte de Node.js está escrita en C++, lo cual no se puede ejecutar en el navegador porque los navegadores solo hablan dos lenguajes, que son JavaScript y WASM. Existen algunos enfoques para resolver este problema de llevar Node.js a los navegadores. Uno de esos ejemplos sería máquinas virtuales en la nube, ejecutándolas para ejecutar código de usuario. Otro ejemplo serían los playgrounds que no dependen de la nube, pero requieren parches personalizados para cada framework. Entonces, lo que estoy tratando de decir es que los parches, si los hay, deben mantenerse al mínimo para emular los comportamientos de Node.js con la mayor precisión posible. En mayo de 2021, Stackbrite anunció los contenedores web. Stackbrite extrae Node.js desde la fuente para permitir ejecutar aplicaciones de Node.js dentro del navegador. Aunque se anunció en mayo de 2021, los contenedores web ya funcionaban bien un poco antes.

Una gran parte de Node.js está escrita en C++, lo cual no se puede ejecutar en el navegador porque los navegadores solo hablan dos lenguajes, que son JavaScript y WASM. El entorno del navegador está diseñado para trabajar con APIs, lo que permite que el código de JavaScript interactúe con la interfaz de usuario, no sé, manejar eventos, y así sucesivamente.

Los navegadores también son entornos aislados. Están en un sandbox. Esto significa que no tienen forma de, quiero decir, no pueden acceder directamente a tu máquina local. Esto es por razones de seguridad. Entonces está claro que hay una incompatibilidad de API. Incluso si compilas Node.js a WASM, incluso si hablan los mismos lenguajes, eso aún no funcionaría porque no tienen las mismas herramientas.

Entonces existen algunos enfoques para resolver este problema de llevar Node.js a los navegadores. Uno de esos ejemplos serían máquinas virtuales en la nube, ejecutándolas para ejecutar código de usuario. Sin embargo, este enfoque tiene algunas desventajas. En primer lugar, es costoso. Tus usuarios pagan por minuto de conexión y también por almacenamiento. Y luego también está el costo ambiental. En segundo lugar, las máquinas virtuales dependen de la conexión a internet. Entonces, sin internet, no hay servicio. ¿Qué pasa si pierdes la conexión Wi-Fi mientras trabajas? Y en tercer lugar, también es peligroso. Este enfoque es popular entre los mineros de Bitcoin, pero también entre los sitios web de phishing, y así sucesivamente. Luego, otro ejemplo serían los playgrounds que no dependen de la nube, pero requieren parches personalizados para cada framework. StackViz tenía uno de esos playgrounds también con una tecnología llamada EngineBlock. Este enfoque no era escalable porque hay muchos frameworks diferentes por ahí. Sin embargo, el punto más importante es que simplemente no emula a Node.js. Solo emula sus capacidades muy limitadas. Como tener que proporcionar parches para cada framework individual.

Entonces, lo que estoy tratando de decir es que los parches, si los hay, deben mantenerse al mínimo para emular los comportamientos de Node.js con la mayor precisión posible. Entonces, ¿qué tal si te dijera que en realidad hay una mejor manera? Bueno, en mayo de 2021, Stackbrite anunció los contenedores web. Así como Randall extrajo el código fuente de V8 para permitir que JavaScript se ejecute fuera del navegador, Stackbrite extrae Node.js desde la fuente para permitir ejecutar aplicaciones de Node.js dentro del navegador. Entonces, Stackbrite emula el comportamiento de Node.js para ejecutarse en el navegador con WASM y con SAMREST con la mayor precisión posible. Aunque se anunció en mayo de 2021, los contenedores web ya funcionaban bien un poco antes. Por ejemplo, aquí hay un episodio de podcast donde Dom y Eric demuestran los contenedores web.

5. Stackbrite's Journey and Growth

Short description:

En 2018, Stackbits fue concebido por los amigos de la infancia Eric Simons y Albert Pai. Su objetivo era reducir las barreras para aprender a programar aprovechando el poder de un navegador. Con un equipo pequeño, Stackbits creció y se desarrolló con contenedores, y ahora opera en 14 países.

Entonces, ¿cómo logró Stackbrite hacer eso? Bueno, la historia se remonta a 2018, en realidad 2017, cuando Stackbits fue concebido. Antes de eso, Eric Simons y Albert Pai, eran dos amigos de la infancia. Estaban dirigiendo una plataforma donde se podía aprender a programar. Se dieron cuenta de que sus estudiantes generalmente tenían dificultades para configurar el entorno. Entonces, en 2018, pensaron que aprovecharían el poder de un navegador para reducir las barreras para aprender a programar. Los primeros dos años fueron muy frugales. Solo eran ellos y dos ingenieros, Dom Elm y Tomek Sulkovski. Entonces, Stackbits fue creciendo en equipo y también desarrollándose con containers. Aquí está, por ejemplo, nuestro equipo en este momento. Estamos en 14 países.

6. Innovation and Future Design

Short description:

Hablemos de cómo descubrimos esta innovación, incluyendo la escritura de todo el sistema de archivos, la implementación de los módulos de ES, el bucle de eventos, la API de serialización de V8, la creación de Turbo e integración de Git. Trabajar en contenedores web significó diseñar para un futuro sostenible, abierto y colectivo. StackBlitz apoya el ecosistema web, toma decisiones audaces sobre tecnologías emergentes y utiliza el búfer de matriz compartida para el procesamiento paralelo. Se unieron a Bytecode Alliance para mejorar todo el ecosistema y son contribuyentes activos del código abierto. Trabajaron con el equipo de SvelteKit en la API de Web Container, lanzada en febrero de 2023.

Entonces, hablemos de cómo, en realidad, descubrimos esta innovación. Esto implicó, por ejemplo, escribir todo el sistema de archivos, lo cual tomó tres iteraciones hasta que finalmente fue escalable y lo suficientemente rápido. Se trataba de implementar los módulos de ES, lo cual incluía, por ejemplo, importaciones circulares y cómo se instanciaban los módulos, implementar el bucle de eventos, implementar la API de serialización de V8, crear Turbo, que es nuestro propio gestor de paquetes, el cual actualmente estamos descontinuando porque ahora tenemos soporte nativo para gestores de paquetes, y luego también descubrir cómo ejecutar comandos de shell e integrar Git. Pero trabajar en contenedores web también significó diseñar para el futuro, un futuro que es sostenible, abierto y colectivo.

Desde el principio, StackBlitz se trató de apoyar todo el ecosistema web y tomar decisiones audaces sobre tecnologías emergentes. Por ejemplo, aunque la especificación de los hilos de Wasm solo ha alcanzado recientemente la fase tres en su camino hacia convertirse en un estándar, esta tecnología ha sido la base de los contenedores web desde hace mucho tiempo, permitiendo una velocidad increíble. Aquí también hay una publicación de blog si quieres leerla, escrita por mi colega, Roberto Vidal. En relación a eso, StackBlitz utiliza el búfer de matriz compartida, que es una característica moderna de JavaScript. Permite el procesamiento paralelo y tiempos de ejecución más rápidos. Elegirlo significaba un soporte inicial limitado para Safari, pero ya no. En enero de 2023, se anunció SafariTP con soporte para el búfer de matriz compartida y muchos de los frameworks funcionan en los contenedores web. Por ejemplo, aquí hay un proyecto de Astro, StealthKit y, por supuesto, Node. Ajustaremos los detalles antes de hacer un anuncio oficial. Pero construir para el futuro también implica un compromiso de mejorar todo el ecosistema. Aquí hay algunos ejemplos de cómo empujar los navegadores a sus límites benefició a la comunidad de desarrollo web. Por ejemplo, detectamos el reciente problema de memoria de V8 WASM, que era un límite estricto en el número de memorias WASM. Aquí está el problema y aquí hay una publicación de blog al respecto. También encontramos el error en los hilos de Firefox, aquí está el problema y aquí hay una publicación de blog al respecto. ¿Qué tal el problema de ARM en las MacBook M1? Aquí está el problema y acaba de ser solucionado. Como puedes ver, StackViz realmente empuja los navegadores a sus límites. Debido a eso, nos unimos a Bytecode Alliance, que es una asociación interindustrial que acelera la transición del mundo hacia la computación segura por defecto.

7. Web Containers and Open Source

Short description:

Mejorar todo el ecosistema no se trata solo de detectar errores. También somos grandes fanáticos del código abierto. En mayo de 2022, trabajamos con el equipo de SvelteKit en la creación de la API de Web Container. Es gratuita para proyectos de código abierto y proyectos con fines de lucro a pequeña escala. Los contenedores web se utilizan en educación, documentación, tutoriales, experimentos y herramientas del lado del cliente. Los contenedores web funcionan creando un iframe para que el contenedor web opere, lo que proporciona un nivel adicional de seguridad y aislamiento.

Pero mejorar todo el ecosistema no se trata solo de detectar errores. También somos grandes fanáticos del código abierto. En nuestro viaje, enviamos solicitudes de extracción a las herramientas que utilizamos. Por ejemplo, WASPAC, parking lot, PMPM, Git isomórfico. O como esta a Node.js, que allanó el camino para los paquetes universales. Pero también apoyamos a Wit no solo patrocinándolo o patrocinando Wit.conf, sino también contratando a su principal mantenedor que trabaja a tiempo completo en Wit. Todo esto es para decir que amamos el código abierto.

En mayo de 2022, trabajamos con el equipo de SvelteKit en la creación de la API de Web Container para que todos pudieran usar esta herramienta para empujar los límites de la web con nosotros. En febrero de 2023, la lanzamos y es gratuita para proyectos de código abierto así como proyectos con fines de lucro a pequeña escala. Si quieres aprender más sobre esto, puedes visitar webcontainers.io. Y allí, puedes ver en funcionamiento un pequeño contenedor web. También puedes probarlo tú mismo. Simplemente ve a webcontainers.new.

Veamos qué se ha construido hasta ahora con los contenedores web. Por ejemplo, en educación. Los contenedores web se utilizan en Total TypeScript, el increíble curso. Se utilizan en la documentación, por ejemplo, y en la demostración incrustada de la documentación de Node.js. Se utilizan como reproducciones de respaldo. Se utilizan en tutoriales, como el tutorial de Sveltekit. Se utilizan en experimentos, por ejemplo, esta aplicación de programación visual, Nano. Aquí también hay una aplicación que utiliza IA para generar otras aplicaciones. Y finalmente, también está la herramienta del lado del cliente. Por ejemplo, Cloudflare Wrangler que es una herramienta para desarrollar trabajadores de Cloudflare. Y tal vez este sea también un buen momento para hablar sobre cómo funcionan los contenedores web. Primero, el contenedor web inicia la aplicación. Esto sucede cuando se crea un iframe en el cual el contenedor web operará. Esto es otro nivel de seguridad. Como recordarás, el navegador es un entorno de sandbox. En el navegador, se ejecuta el contenedor web en su propio iframe para que no tenga acceso a ninguna información en la página de tu sitio web. Así que es un doble aislamiento.

8. Funcionalidad de los Contenedores Web

Short description:

Una vez que el contenedor web se inicia, los trabajadores dedicados funcionan como procesos para tu programa. Los contenedores web optimizan la instalación de dependencias, lo que la hace más rápida que en local. Si tu aplicación cuenta con un servidor web, los contenedores web proporcionan una pila de red TCP virtualizada y permiten abrir URL que están aisladas de forma segura de otras instancias del navegador. Los contenedores web son rápidos y manejan las dependencias de manera eficiente. Si experimentas algún problema, por favor avísanos.

Una vez que el contenedor web se inicia, entran en juego los trabajadores dedicados. Funcionarán como procesos para tu programa. Si estás instalando dependencias o si hay alguna situación con el administrador de paquetes, ya sabes, sucediendo, los containers web realizarán solicitudes para iniciar este dominio, que sirve como un proxy a los registros de paquetes gracias a los cuales la instalación está optimizada. Por lo general, de hecho, la instalación de dependencias es más rápida que en local. Si no es así, avísanos.

Y si tu aplicación cuenta con un servidor web, los containers web incluyen una pila de red TCP virtualizada que se monta en la API del service worker de tu navegador. Entonces, si tu aplicación Node.js ejecuta un servidor de desarrollo, se te pedirá que abras una URL que apunta a un dominio externo que en realidad está alimentado por un service worker localmente dentro de tu navegador. Debido a esta conexión, puedes abrir esta URL en otra pestaña y está aislada de forma segura de otra instancia del navegador. Eso también significa que incluso si pierdes la conexión a Internet a mitad de camino, aún puedes ver que esta URL funciona siempre y cuando el service worker esté registrado. Entonces, los containers web son realmente rápidos, más rápidos que en local debido a cómo manejamos las dependencias. Aquí tienes una demostración de PMPM, hasta cuatro veces más rápido que en local, y de Node.js. Nuevamente, si algo tarda más que en local, avísanos. Así que ahora, para resumir, ¿por qué usarías los containers web? Primero, es una forma segura de ejecutar código. Está aislado dos veces. Es una forma rápida de probar ideas. Es solo una URL y puedes programar. Y luego puedes compartirla con alguien. Es una forma económica. No tienes que pagar para ejecutarlo o usarlo. Tenemos planes de pago, por supuesto, pero la mayoría de nuestros usuarios disfrutan de Stack Vista de forma gratuita. Y antes de pasar a la última parte, echemos un vistazo al tweet que vi el otro día. Bueno, todos conocemos los problemas de guardar, clonar, cambiar a una rama, ejecutar dependencias, ejecutar el servidor de desarrollo. Quiero decir, mira la cantidad de likes. Hay tantas personas que se relacionan con esto. ¿Y si te dijera que esto ya no es un problema? Los containers web hacen que sea un placer revisar PR y verificar reproducciones. Aquí tienes, por ejemplo, un PR en Elkzone, que es un cliente de Mastodon muy bonito. En el PR, puedes ver un bot de la aplicación CodeFlow. Este botón proporciona un entorno instantáneo y desechable. CodeFlow IDE es una réplica de VS Code, pero alimentado por containers web, lo que significa que ejecuta Node.js dentro del navegador. Obtienes un entorno con solo un clic. Si haces clic en el botón de PR, verás todo el entorno con el servidor de desarrollo en ejecución y todas las extensiones recomendadas cargadas para ti. Si quieres probarlo, ve a cualquier repositorio de GitHub y simplemente agrega PR.new al principio. De esta manera, te unirás a dos millones de desarrolladores que utilizan los containers web mensualmente. Y eso es todo. Si tienes alguna pregunta, encuéntrame en Sylvia Vargas, o simplemente contáctame. Gracias por tenerme aquí.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.