Node.js Native Add-Ons Explained

Vamos a repasar algunas cosas en esta charla. Por supuesto, ¿qué son los complementos nativos de Node.js? Vamos a encontrarnos con un par de casos de uso. Uno, una API ABI estable para Hermes que ya está en uso. Y dos, una prueba de concepto de compartir bibliotecas entre ecosistemas. Lo resumiremos todo después.

Entonces, ¿qué son los complementos nativos de Node.js? Bueno, Node.js tiene sus propios módulos nativos llamados complementos nativos. Por ejemplo, para que Node.js interactúe con SQLite3, hay un paquete NPM para eso. Y así como los módulos nativos de React se escriben con JSI, los complementos nativos de Node.js se escriben con NodeAPI, que es igualmente independiente del motor. Ahora, para ponerlo visualmente, es así. NodeAPI ocupa la misma posición entre el código nativo y los motores de JavaScript que JSI.

Entonces, ¿por qué deberíamos preocuparnos? Ya tenemos JSI. ¿Qué más necesitamos? Bueno, en primer lugar, NodeAPI es increíblemente popular. Entonces, si lo mides solo por las descargas por semana de Node add-on API, que es comúnmente importado por complementos nativos de Node.js basados en C++, hay 20 millones de descargas por semana. Muy popular. Es impulsado por la comunidad. Es un estándar de facto de la industria, y está disponible para varios lenguajes. Entonces, en lugar de escribir en C++, puedes escribir en Swift, como, ya sabes, podemos hacer con Expo modules y Nitro modules, pero también Rust, C Sharp, Nim, Zig, Go. Y puede expresar prácticamente cualquier cosa que ECMAScript pueda. ¿Quieres proxies, puedes tenerlo. Puedes hacer extensiones de clase, métodos estáticos, todo tipo de cosas, de manera muy idiomática, en lugar de tener que hacer muchos trucos de prototipos, por ejemplo. Hay una interrupción de primera clase entre el contexto nativo y JavaScript. Entonces, tienes tiempos de vida, tienes funciones asíncronas, tienes subprocesos, ese tipo de cosas. Y es ABI estable, lo que veremos más adelante.

Entonces, ¿es todo esto solo teoría? Es una cosa decir que Node API sería genial, tiene todas estas características, pero ¿cuál es la historia sobre llevarlo a React Native? Bueno, la verdad es que ya se usa en React Native Windows. Así que me gustaría contar una historia sobre una API ABI estable para Hermes. Pero para explicar eso, primero necesitamos estar claros sobre qué es un ABI. Así que aquí tenemos una hermosa imagen de algunos binarios, que expresa parte de esta historia. Entonces, una interfaz binaria de aplicación es la versión compilada de una API. Entonces, mientras que cuando estás tratando con APIs estás tratando con conceptos humanos, como clases y declaraciones y funciones y ese tipo de cosas, un ABI es un nivel más bajo. Es como si dijera dentro de este gran blob binario, ¿dónde encuentro las cosas que necesito y qué significa? Entonces, define el conjunto de funciones y sus firmas, las estructuras de datos, por ejemplo, diseños de estructuras y enumeraciones, convenciones de llamadas a funciones, manejo de errores, y gestión de memoria.

Y un ABI ideal es tanto seguro como estable. Permítanme explicar lo que quiero decir con eso. Hay un concepto de seguridad ABI, donde tienes tu aplicación y una biblioteca que consume, digamos Hermes. Y para construir tu aplicación lo más rápido posible, quieres estar construyendo tu aplicación y tu código de usuario en modo de depuración. Pero bibliotecas como Hermes, las querrás precompiladas en modo de liberación. No quieres estar compilándolas desde cero cada vez. Y quieres que se ejecuten lo más rápido posible. Por eso quieres todas las optimizaciones de la compilación de liberación.

Ahora, la seguridad ABI, por lo tanto, permite que un binario se use en tu aplicación sin recompilación, independientemente del modo de compilación, compilador o lenguaje. La estabilidad del ABI es otra cosa que va junto con eso. Tenemos nuestra aplicación de nuevo. Tenemos Hermes de nuevo. Pero, digamos que queríamos intercambiar una versión antigua de Hermes por una más nueva, sin recompilar el resto de nuestra aplicación. De esto se trata la estabilidad del ABI. Es un compromiso con la compatibilidad hacia atrás, diciendo, por ejemplo, si vamos a agregar cualquier nuevo caso a un enum o cualquier nuevo método a una clase, lo hacemos, ya sabes, nos comprometemos a hacer las cosas de manera aditiva, y nunca eliminamos cosas.

Así que, entraremos en por qué eso sería particularmente útil en un momento. Así que, esto se pone en práctica en React Native Windows. Para realizar estos beneficios, React Native Windows utiliza un fork de Hermes, que implementa una API basada en Node API. Desde su desarrollo, Hermes ha comenzado a desarrollar una API oficial, pero por ahora, estudiemos cómo funciona Hermes Windows. La forma en que comenzaron las cosas, la biblioteca Hermes expondría JSI, como la API por la cual React Native lo usa. JSI siendo una biblioteca de C++ no es segura para ABI. En el futuro, esto mejorará un poco, tendremos una API segura para ABI de Hermes, contra la cual React Native puede codificar. Pero, como eso no estaba originalmente disponible, Hermes Windows tomó un cierto enfoque para exponer una API segura para ABI para React Native Windows. ¿Cómo hicieron eso? Bueno, hicieron una biblioteca llamada Node API, JSI. Y entraré en eso en un segundo, pero en lugar de exponer JSI, que no era seguro para ABI, expusieron Node API, que es seguro para ABI. Y luego, Node API JSI puede exponer JSI a React Native Windows, y lo implementa sobre Node API. Esto es un poco confuso, pero así es como está todo configurado. Lo clave de esto es que Node API JSI es solo fuente. Entonces, cualquier símbolo que esté exportando, símbolos JSI, no importa porque son internos al DLL de React Native.

Así que, no importa que JSI no esté deshabilitado para ABI si no es, ya sabes, si es privado. Así es como lo hicieron. Y los beneficios de esto son, concretamente, que ahora podemos usar el último Hermes independientemente de React Native Windows. Podemos usar Hermes preconstruido en modo de liberación para una ejecución más rápida, mientras construimos el resto de nuestra aplicación en modo de depuración para compilaciones más rápidas. Todo esto gracias a Node API.

Ahora, otro caso de uso son las bibliotecas de ecosistema cruzado. Me gustaría hablar sobre NativeScript. Entonces, esta es una biblioteca de ecosistema cruzado que nos gustaría llevar a React Native, ya que es exactamente el tipo de cosa de la que creo que React Native podría beneficiarse. Pero primero, para explicar por qué querríamos esto, solo quiero mostrar qué es por un momento. Entonces, NativeScript es una biblioteca para llamar a APIs nativas desde JavaScript. Digamos que querías llamar a un número de teléfono, darles una plataforma, iOS, puedes hacer acceso idiomático de JavaScript al SDK de iOS. Entonces, aquí estamos interactuando con UIKit. Estamos obteniendo la aplicación de UI, y estamos llamando a un método con una mezcla de argumentos de JavaScript. Así que verás que el argumento del medio es un objeto simple que se convierte en un NSDictionary. Pero los otros argumentos, ya sabes, tenemos el resultado de una llamada de función, y estamos pasando una función de JavaScript, también. Así que es realmente algo mágico. Y podemos hacer lo mismo para Android. Y la idea de esto es que significaría que no tenemos que lidiar tanto con código nativo. Podemos hacer JavaScript en línea que llama a APIs nativas por nosotros. Así que es un ajuste muy bueno para React Native. Y de hecho tenemos una prueba de concepto de esto funcionando en Node.js.

La forma en que lo abordamos fue que hicimos un addon nativo de Node.js. Pensamos, bueno, ¿podríamos llevar esto a React Native? El problema es que los addons nativos de Node.js no se pueden usar tal cual, incluso en React Native Windows. Porque aunque el script nativo está disponible como un addon nativo de Node.js, Hermes Windows solo implementa la API subyacente. Node API. Así que esto es algo que probablemente debería explicar antes. Si Node API es este subconjunto, los addons nativos de Node.js se envuelven alrededor de él. Y lo clave sobre los addons nativos es que implementar toda esa especificación es necesario para implementar el soporte de carga de módulos para que puedas simplemente hacer require de tu addon. Pero dado que la biblioteca es mayormente Node API y solo hay un pequeño bit para esa lógica de carga de módulos al final, ¿podemos aún usarlo de alguna manera? Hay una manera. Aquí está cómo lo hice.

Para inicializar el addon, solo para que lo sepas, el enfoque típico en Node.js sería este. Adquirirías la biblioteca. Y eso hace que el módulo se evalúe, lo que hace que los módulos inicialicen una ejecución, que finalmente llama a nuestra función interna, que hemos llamado objective C bridge init. Y eso ejecuta toda la lógica para configurar estos enlaces. Entonces, ¿cómo podríamos hacer eso en el mundo de React Native, donde tenemos Node API, pero no soporte de carga de módulos? Aquí está nuestro enfoque modificado.

Enlazaríamos automáticamente algo que vamos a llamar native script XC framework. Entonces, para cada arquitectura que queramos soportar, tendremos una recompilación de native script.node. Y native script.node es al final del día una biblioteca. Puedes incrustarla de varias maneras. Puedes agregarla al final del binario o meterla en XC framework. Y una vez que tenemos ese código nativo disponible en nuestra aplicación, podemos llamar manualmente a objective C puenteándolo desde el lado nativo. Te mostraré cómo lo hacemos.

Entonces, lo que hice fue recompilar Hermes Windows para iOS porque esta biblioteca en particular trata sobre el puente objective C, así que tuvimos que usar iOS para hacer cualquier tipo de prueba de concepto. Luego parcheé el siguiente archivo para configurar Node API. Es la fábrica ejecutiva de Hermes. Aquí es donde Hermes obtiene el Hermes de un tiempo de ejecución que se inicializa en tu aplicación React Native. Así que, solo unas pocas líneas aquí. Creamos un entorno Node API en el momento en que estamos haciendo el tiempo de ejecución de Hermes y abrimos un alcance de entorno Node API. Y solo una línea extra aquí para la configuración de Node API de native script. Llamamos a objective C bridge init pasando ese entorno y luego nos ponemos en marcha. Idealmente, esto no involucraría parchear la fábrica ejecutiva de Hermes. Node API se configuraría desde el principio. Y tal vez en usuario y tal vez en un módulo JSI. No estoy seguro si eso es demasiado tarde en el ciclo de vida para hacerlo. Idealmente, podríamos entonces llamar a objective C bridge init en el espacio del usuario. De todos modos, vamos a intentarlo. He creado una plantilla de expo. Esto está en una versión más antigua de React Native. Pero el concepto y los principios aún están ahí. Así que puedes jugar con ello también.

Una pequeña demostración simple. Podemos leer el nivel de batería sin involucrar un módulo nativo simplemente escribiendo algo de JavaScript inline. Así que, podemos obtener UI device e inspeccionarlo y obtener el nivel de batería.

Otra cosa que podemos hacer es obtener una depuración adecuada de datos nativos. Así que, por ejemplo, aquí obtenemos la vista raíz y preguntamos cuál es la descripción de depuración. Y podemos ver todo tipo de cosas interesantes. Podemos ver los valores de los punteros. Podemos ver el marco. Y esto puede ser realmente útil para distinguir una vista nativa de otra, lo cual podría ser realmente interesante para una lista virtual, por ejemplo.

Y aquí hay algo divertido. Podemos hacer cambios en la vista. Así que, aquí obtuve la vista raíz nuevamente y establecemos el color de fondo en ella. Esto fue bastante sorprendente porque estamos en el hilo de JS y pudimos hacer un cambio en la UI. Esto debería haber hecho que la aplicación se bloqueara. Pero resulta que el color de fondo es una propiedad segura para hilos. Así que, nos salimos con la nuestra. Pero si queremos hacer un trabajo serio en el hilo de la UI, hay una manera. Y esto involucra React Native reanimated. Usamos un worklet de React Native reanimated y ejecutamos ese worklet en el hilo de la UI. Ahora, diría que la experiencia del desarrollador aquí no es ideal. Así que, me gustaría idear una mejor API para esto en el futuro. Pero solo para mostrar una prueba de concepto, incluso podríamos acceder al hilo de la UI de manera segura con esta metodología. Y aquí creamos una alerta nativa usando APIs de UI inline. Así que, todo esto es para decir que realmente no hay límite para los complementos nativos de Node.js. Puedes hacer cosas realmente nativas desde el lado de JavaScript.

Así que, entremos en la conclusión. Comenzando con mis esperanzas para el futuro. Me gustaría ver Node API integrado en Hermes. Esto está realmente en progreso.

Hay un PR abierto para esto ahora mismo. Me gustaría ver soporte para complementos nativos de Node.js. No tengo idea de qué tipo de cronograma podríamos ver alguna vez para esto. Pero eso realmente abriría todo este ecosistema.

La finalización de la API oficial ABI estable de Hermes también sería increíble porque eso llevaría al objetivo. Los módulos nativos actualmente codifican contra JSI. Así que, es una historia realmente mala si quieres distribuir módulos nativos preconstruidos ABI estables. Así que, una vez que la estabilidad ABI llegue a ellos, puedes comenzar a precompilarlos. Y distribuirlos de manera flexible.

Y finalmente, más colaboración entre ecosistemas. Me encantaría que dejáramos de reinventar la rueda y trabajáramos juntos con personas de Electron, por ejemplo, y Node y comenzáramos a reutilizar algunas de sus cosas y compartir algunas de las nuestras. Así que, en resumen, los complementos nativos de Node.js son el estándar de facto de módulos nativos de JavaScript y se basan en API ABI estable, Node API. La estabilidad ABI es importante para la flexibilidad en el uso de bibliotecas preconstruidas, como usar una cosa en modo de depuración mientras el resto de tu aplicación se compila en modo de lanzamiento o viceversa, lo que sea que quieras hacer. Y la colaboración entre ecosistemas está actualmente limitada sin el soporte completo para complementos nativos de Node.js pero no es imposible con soluciones alternativas.

También se está trabajando para integrar Node API en Hermes, y estoy muy emocionado por eso. Así que, terminaré con algunos agradecimientos. Gracias al equipo de React Native Windows por implementar todos estos conceptos y probar su validez. Al equipo de Hermes por ser receptivo a llevar Node API al núcleo. Al NativeScript TSC por involucrarme en este mundo de pensar en Node API con esta prueba de concepto de ejecutar NativeScript en Node.js. Y luego a Expo. Necesitaba una forma de compartir estas muestras y las plantillas de Expo fueron la manera perfecta de hacerlo. Así que, gracias por ver. Espero que podamos usar más Node API en el futuro y espero que podamos compartir más entre ecosistemas.