Construyendo un Entorno de Ejecución Node.js para el Navegador

Rate this content
Bookmark

Recorreremos lo que se necesita para construir un entorno de ejecución Node.js para el navegador, los desafíos que descubrimos en el camino y las soluciones que construimos para esos desafíos.

This talk has been presented at React Summit US 2023, check out the latest edition of this React Conference.

FAQ

Nodebox es un entorno de ejecución compatible con Node.js diseñado para funcionar en el navegador. Fue creado para permitir que la biblioteca de juegos Sandpack ejecute pequeños proyectos, como ejemplos de Next.js y aplicaciones Next.pressjs, principalmente con fines de documentación.

Para desarrollar Nodebox fue necesario construir un sistema de archivos, un servidor HTTP, soporte para websockets, módulos, capacidad de buscar módulos NPM y soporte para procesos hijos, además de asegurar la compatibilidad con muchas bibliotecas y frameworks.

En Nodebox, un servidor HTTP se simula mediante el uso de iframes y un proceso de mensajes entre el trabajador y el administrador de vistas previas. Esto permite iniciar un servidor HTTP y manejar solicitudes y respuestas como si se tratara de un entorno Node.js real.

El sistema de archivos en Nodebox funciona sincronizando las escrituras de archivos en un estado centralizado del sistema de archivos y luego propagando esos cambios a todos los trabajadores, asegurando la consistencia de los datos entre diferentes módulos y procesos.

Las solicitudes HTTP en Nodebox se manejan pasando la solicitud a través de un trabajador de servicio, el cual comunica con un relevo de vista previa y finalmente al administrador de vista previa que gestiona las solicitudes. Este proceso simula la operación de un servidor HTTP dentro del entorno de Nodebox.

Nodebox ofrece una simulación de WebSockets mediante la sobrescritura del objeto global WebSocket, permitiendo la comunicación como si se tratara de un WebSocket real, pero gestionado dentro de su entorno virtualizado.

Nodebox se puede probar en NodeBox.Codesandbox.io, donde hay disponibles varias plantillas basadas en Sandpack que incluyen Node.js, Next.js, Vite, React, Vue, Spelt y Astro, permitiendo a los usuarios experimentar con diferentes entornos compatibles con Node.

Jasper De Moor
Jasper De Moor
13 min
15 Nov, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute los desafíos y la colaboración involucrados en la construcción de Nodebox, un entorno de ejecución compatible con Node.js para el navegador. Proporciona una visión general de cómo funciona Nodebooks, incluyendo el administrador principal, las vistas previas y los trabajadores web. La charla también cubre la simplicidad y velocidad de lectura desde el sistema de archivos en Nodebooks. Destaca la complejidad de implementar el soporte HTTP y la simulación de WebSocket en Nodebox. Por último, menciona la capacidad de construir un servidor web utilizando Nodebox y proporciona información sobre las plantillas disponibles.

1. Construyendo Nodebox: Desafíos y Colaboración

Short description:

Hola, soy Jasper. Hablaré sobre cómo construimos Nodebox, un entorno de ejecución compatible con Node.js para el navegador. Necesitábamos construir un sistema de archivos, un servidor HTTP, soporte para websockets, módulos y la capacidad de buscar módulos NPM. Tuvimos ayuda de las bibliotecas existentes en el ecosistema de Browserify.

Hola, soy Jasper. Soy un ingeniero de personal en Codesoundbox, y voy a dar una charla sobre cómo construimos nuestro entorno de ejecución compatible con Node.js para el navegador llamado Nodebox. Entonces, ¿por qué realmente construimos un entorno de ejecución compatible con Node.js para el navegador? Queríamos construir un entorno de ejecución compatible con Node.js porque queríamos permitir que nuestra biblioteca de juegos, Sandpack, ejecute pequeños proyectos. Como por ejemplo un pequeño ejemplo de Next.js, un ejemplo de feed, o una aplicación Next.pressjs. Obviamente para los propósitos de documentación.

¿Y qué necesitábamos construir para hacer esto posible? Hay muchas cosas que entran en Node.js. Por ejemplo, tuvimos que construir un sistema de archivos, un servidor HTTP y soporte para websockets, tuvimos que construir módulos, tuvimos que ser capaces de buscar módulos NPM. También tuvimos que asegurarnos de que teníamos soporte para procesos hijos, ya que la mayoría de las bibliotecas y frameworks dependen mucho de eso. Y también hay muchas más bibliotecas más pequeñas y otras bibliotecas estándar en Node.js que tuvimos que soportar para hacer todo esto funcionar. Así que en realidad tuvimos mucha ayuda de las bibliotecas existentes, porque hay muchas cosas por ahí del ecosistema de Browserify. Por ejemplo, está assert, y está como zlib. También está un buffer y eventos, o decodificador de cadena de ruta, como utilidades de URL. Stream legible por el equipo de Node, que nos ayuda a construir soporte para streams. Y luego también está como crypto, y un montón

2. Resumen de Nodebooks y Sistema de Archivos

Short description:

Así que un resumen general de cómo funciona realmente Nodebooks. Tenemos un administrador principal que controla todo en nuestro entorno virtual. Genera procesos, imitando los procesos reales de Node. También tenemos vistas previas, que actúan como un servidor HTTP. Nuestros procesos Node son trabajadores web con su propio proceso contenido. Utilizamos trabajadores web para inicializar cada trabajador y hacer el trabajo de inicialización de construcción del árbol del sistema de archivos, cargar archivos de ensamblaje web y esperar a que termine. Una vez que el trabajador está listo, lo enviamos de vuelta al principal y podemos ejecutar comandos como Next.js. Envolvemos el módulo en nuestro propio global para hacerle creer que se está ejecutando en un entorno de nodo. Nuestro sistema de archivos funciona con el proceso principal teniendo todo el estado y los trabajadores teniendo consistencia eventual. Al escribir en el sistema de archivos, la escritura se sincroniza y se envía al proceso principal para sincronizarla en todo el estado de la aplicación.

y otras que no están listadas en esta diapositiva. Así que un resumen general de cómo funciona realmente Nodebooks. Así que tenemos nuestro administrador principal, que controla todo en nuestro entorno virtual. Y genera procesos, que son procesos reales de Node, o intentan ser procesos de Node, los imitan. Y luego también tenemos vistas previas, que son algo así como tu servidor HTTP, que pasa por nuestro administrador de vistas previas, que construimos, que luego inicia iframes para imitar este comportamiento del servidor HTTP. Y nuestros procesos Node son en realidad web workers, que también tienen su propio proceso contenido similar a cómo funciona Node. Y entonces, ¿cómo funciona un proceso Node en nuestro entorno? Como dije antes, utilizamos web workers. Para hacer esto, inicializamos cada trabajador enviando un buffer del sistema de archivos y variables de entorno y un montón de otras pequeñas opciones de configuración que tenemos en Nodebox. Bueno, una vez que esto sucede, el trabajador se pone en marcha y comienza a hacer su trabajo de inicialización, que es construir el árbol del sistema de archivos, cargar algunos archivos de ensamblaje web que utilizamos por ejemplo, para transpilar nuestro código o algunas cosas como probablemente la compresión, que realmente no existe en el navegador en este momento. Y también tenemos cosas como esperar a que termine al final. Y luego entramos en la carga del resto de las cosas. Entonces, una vez que el trabajador está listo, lo enviamos de vuelta al principal. Y una vez que está en el principal, el principal sabe que nuestro trabajador está listo. Y ahora, podemos hacer como ejecutar un comando. Por ejemplo, ejecutar Next.js es tan simple como pasar el comando JSON next y luego se inicia todo un servidor Next.js. Hace esto yendo a nuestros nodos modules y resolviendo el binario next que en realidad es solo un archivo JavaScript al final. Entonces, resolvemos eso que termina siendo como .bin slash next y luego tiene un enlace simbólico a slash node module slash next slash CLI.MJS o algo así. Y luego ejecutamos ese script real como node, el archivo resuelto y luego lo pasamos como argumentos a nuestro módulo. Y luego lo usamos para evaluar el módulo. Cómo hacemos eso es envolviendo nuestro módulo en nuestro propio global que construimos que contiene la mayoría de los globales, los nodos modules esperan como el módulo, global require hay un par de otras cosas del módulo ES y luego global this que es todo diferente del navegador y tratamos de hacerle creer que se está ejecutando en un entorno de nodo en lugar del navegador real. Así que también establecemos ciertos globales del navegador en indefinido o nulo. Y luego lo ejecutamos en una función. Lo envolvemos en una función con nuestros argumentos globales. Así que el código cree que estos son nuevos globales en lugar de los globales reales que tiene el navegador. Y eso también lo hacemos aplicar donde anulamos los discos para que sean nuestros discos globales en lugar de los discos del navegador. Así que realmente cree que está dentro de un entorno de nodo mientras todavía se está ejecutando dentro de un navegador. Entonces, ¿cómo funciona nuestro sistema de archivos? Nuestro sistema de archivos funciona de tal manera que nuestro proceso principal tiene el estado completo del sistema de archivos y todos nuestros trabajadores tienen consistencia eventual. Por ejemplo, aquí tenemos un ejemplo de cómo se escribe en un sistema de archivos. Entonces en el módulo, tienes importfs y luego llamas a fs.write. Esa escritura luego se envía a nuestro estado del sistema de archivos que instantáneamente lo sincroniza en su propio estado y luego envía un mensaje a nuestro bus de trabajadores al proceso principal para decir que he escrito algún archivo. ¿Puedes sincronizarlo en todo nuestro estado de la aplicación? Y luego el estado principal del sistema de archivos también recibe eso, actualiza su estado interno y luego

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

Documentación Full Stack
JSNation 2022JSNation 2022
28 min
Documentación Full Stack
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
Puerta de entrada a React: La historia de React.dev
React Summit US 2023React Summit US 2023
32 min
Puerta de entrada a React: La historia de React.dev
The Talk discusses the journey of improving React and React Native documentation, including the addition of interactive code sandboxes and visual content. The focus was on creating a more accessible and engaging learning experience for developers. The Talk also emphasizes the importance of building a human API through well-designed documentation. It provides tips for building effective documentation sites and highlights the benefits of contributing to open source projects. The potential impact of AI on React development is mentioned, with the recognition that human engineers are still essential.
TypeScript para Autores de Bibliotecas: Aprovechando el Poder de TypeScript para DX
TypeScript Congress 2022TypeScript Congress 2022
25 min
TypeScript para Autores de Bibliotecas: Aprovechando el Poder de TypeScript para DX
TypeScript for library authors offers benefits for both internal and external use, improving code quality and providing accurate understanding of libraries. Documentation and examples should be in code to provide up-to-date information. Testing types alongside unit tests ensures accurate typing. Managing changes and exposing types requires careful versioning. Deep integration of types improves usability. Using a map in TypeScript allows for simpler implementation and customization. Leveraging types in libraries can generate code based on user access. TypeScript integration with Nuxt provides support and type declarations.
La Fuente Legendaria de la Verdad: Componentiza tu Documentación!
React Advanced Conference 2021React Advanced Conference 2021
24 min
La Fuente Legendaria de la Verdad: Componentiza tu Documentación!
Welcome to this session about documentation in a command-driven era. The Data Axis framework provides a comprehensive approach to documentation, covering different areas of the development process. Component-driven development and MDX syntax enable faster development, simpler maintenance, and better reusability. Embedding components in Markdown using MDX allows for more advanced and useful documentation creation. Tools like Storybook and Duxy with MDX support are recommended for documentation solutions. Embedding documentation directly within components and migrating to MDX offer a comprehensive documentation experience and open up new possibilities for embedding and improving documentation.