Módulos Nativos Oxidados para React Native

Hola, esta es mi charla sobre Veric, un generador de enlaces de Rust para React Native, módulos de Node API. Y quiero ser muy claro en esto. Lo que verán hoy aquí, funciona. Todavía se está mejorando y apenas funcionó hace unas dos semanas. Así que mientras grabo esta charla, la mayor parte del código aún no está publicado. Y mi esperanza es que lo esté cuando se emita la grabación. Vean esto como una aspiración y una vista previa tecnológica temprana de lo que está por venir.

Primero, mi nombre es Crane. Soy un ingeniero de software senior en MongoDB. Ayudo a construir herramientas para desarrolladores en MongoDB, principalmente compass y aplicaciones GUI basadas en electron para navegar por su base de datos y su clúster de bases de datos. También ayudo a mantener los dispositivos Atlas para cubrir TypeScript, anteriormente conocido como RealmJS. Es mucho código TypeScript, algo de código C++, y soporta múltiples entornos de ejecución sistemas operativos y motores de JavaScript. Y fuera del trabajo, soy un orgulloso padre de dos niñas de seis años y un niño de dos años todos niñas. Y vivo en Rustkilde, al oeste de Copenhague en Dinamarca. Y además de pasar tiempo con mi familia, también trabajo en MongoDB unas 30 horas a la semana. Y fuera de eso, me gusta construir en público. Y para esto, acepto patrocinios en GitHub, especialmente de CoreStack. Y escríbeme en BlueSky si tienes algún comentario. Lo aprecio mucho.

Entonces, ¿por qué me importan los módulos nativos y React Native? He estado luchando con esta bestia durante siete años. Y en el otoño del año pasado, MongoDB decidió reenfocar sus esfuerzos y deprecar la base de datos en la que estaba trabajando. Tengo mucho costo hundido en el espacio del problema, en React Native y en nuestra comunidad. Y me siento obligado a compartir mis aprendizajes de mi tiempo construyendo este SDK. A medida que también surgen oportunidades para crear nuevos módulos nativos para React Native, soy consciente de que nunca quiero escribir y depurar un enlace manual nuevamente. Y si es posible, me encantaría construir para la menor cantidad de motores de JavaScript posible. Vamos a sumergirnos en Rust. Entonces, ¿qué hace que sea difícil combinar React Native, que está escrito en C++ con una biblioteca de Rust? Primero, sus disposiciones de datos no coinciden automáticamente. Y muchos de los conceptos no se trasladan entre Rust y C++. Aquí hay un par de ejemplos de cómo no son compatibles. Y terminas bajando al denominador común más bajo cuando te comunicas entre los dos.

Llamamos a esto la foreign function interface a menudo, o también a veces se refiere como un puente C. Y este es un ejemplo de esto. Hice un diagrama aquí que representa la secuencia de llamadas entre componentes. Como esta es la arquitectura más utilizada al envolver una biblioteca de Rust en un módulo Turbo de React Native.

Cuando se carga el módulo Turbo, llama al motor de JavaScript a través de JSI para exponer sus funciones nativas a través del código JavaScript de la aplicación, ya sea a través de la función host o la abstracción de objeto host proporcionada por JSI. Después de esta inicialización, el JavaScript puede llamar al módulo Turbo. Y en este ejemplo, la aplicación llama a get item pasando una cadena. Y este código, básicamente llama a través de la función host en el C++, que luego llama al código de la biblioteca real a través del puente C.

Y observe aquí cómo el puente C es específico del dominio. Tiene esta llamada a get item. No está abstraído. Es como un lenguaje muy concreto de la biblioteca, lo cual es una tarea difícil de implementar y probar como autor de la biblioteca, este puente C, este puente C personalizado. Y debido a que el consumidor del puente C, se registra en la aplicación usando JSI, que no es ABI seguro. Esto no se puede poner en un preconstruido de manera confiable. Así que tienes que compilar esto en la máquina del desarrollador de la aplicación.

Y también observe que mientras el módulo Turbo implementa una especificación generada por código, su implementación interna y la forma en que llama al puente C, es seguro en cuanto a tipos, pero podría estar usando y llamando incorrectamente, lo cual es también otro problema potencial. Y esto se debe a que llamar desde bibliotecas de Rust a C++ y con estos y al revés, rápidamente se vuelve muy complicado y propenso a errores, especialmente para tipos de datos complejos, como structs y cosas con objetos con tiempos de vida, referencias a objetos con tiempos de vida. Y a menudo es repetitivo, verboso. Hay muchas buenas razones por las que nos gusta escribir código en un lenguaje de nivel superior. Y a menudo conduce a fugas de memoria y fallos en tiempo de ejecución porque la gestión de memoria como hacerlo manualmente y también el código consciente del tiempo de vida de los objetos, es muy difícil de escribir de una buena manera. Creo que básicamente, es como un punto interminable de frustración y dolor y potencialmente será ilegal en el futuro también. Así que no es muy divertido depurar estas cosas, escribirlas o depurarlas. Y aquí está mi dolor de corazón, si C es alguna vez parte de tu proyecto, debería ser generado y considerado efímero, una especie de representación intermedia. Y no debería haber necesidad de comprometer esto en tu repositorio si se puede evitar.

Entonces, ¿cuáles son las alternativas a esto? Así que la primera alternativa que quiero mencionar es UniFFI de Mozilla. Puedes usar esto para aliviar el dolor o al menos parte del dolor. Presenta múltiples lenguajes de destino. Así que React Native siendo uno de ellos. Y está optimizado para un amplio soporte de plataformas de destino y utiliza mucho de marshalling y copia de datos para lograr eso. Favorece la facilidad de implementación y comprensión sobre el rendimiento como escriben en su propia documentación. Y este podría ser el compromiso adecuado para ti. Mientras estaba construyendo una prueba de concepto para un binding UniFFI para el auto-merge trade en diciembre, noté el código rush que necesitaba escribir allí para básicamente prepararlo para ser expuesto de esta manera era considerablemente, era el más, había mucho código que necesitaba escribir para exponerlo de una manera confiable.

Otra alternativa es SaferFFI de Dido, y está mejorando la experiencia del desarrollador de mantener una interfaz de función extranjera o ZBridge. Es usado y mantenido por Dido, como dije, en esta solución de sincronización peer-to-peer local first. Y ayuda a deducir bloques seguros, lo siento, ayuda a reducir los bloques inseguros en tu código rush y genera un encabezado C para el consumidor, pero el lado consumidor del puente aún necesitas implementarlo y mantenerlo manualmente. Y en el contexto de la estabilidad ABI y React Native, también podrías haber oído hablar del Hermes ABI. Es un ABI estable experimental basado en C para Hermes. Así que en la superficie, exactamente lo que necesitamos, pero no es realmente para consumo general. Y en sus propias palabras, no resuelve inmediatamente la estabilidad ABI para bibliotecas nativas dirigidas a React Native. Así que no React Native en sí, sino las bibliotecas que se construyen sobre él. Y esto se debe a que las bibliotecas aún consumirán un puntero de tiempo de ejecución C++ JSI proporcionado por React Native y no Hermes. Y el equipo de Hermes es consciente de esto, y está dentro del alcance de sus esfuerzos para resolver esto eventualmente. Hasta que esté listo, creo que tenemos otras y más, en mi opinión, mejores alternativas disponibles. Así que esto sucedió en el React Summit US el año pasado. Al final del año, estaba presentando una charla sobre la construcción de módulos nativos C++ JSI para React Native.

Y mientras hacía eso, Jamie Burch también dio una charla sobre el estado de los complementos nativos de Node API en React Native. Recomiendo encarecidamente ver esta charla. Y cuando lo hice, algo hizo clic para mí. Entonces, ¿por qué estoy tan entusiasmado con estos módulos de Node API? ¿Y por qué lo estaba Jamie? Bueno, es porque es una alternativa ABI segura a JSI y la API de Hermes que mencioné antes. Y es una API basada en C, y también tiene un envoltorio de C++ de nivel superior, al igual que JSI sería para la API de Hermes. Y hay una comunidad próspera de ecosistemas existentes. Lo siento, hay un ecosistema próspero de herramientas y entornos de ejecución y bibliotecas disponibles para Node API. Está adoptado por Node.js en sí, por supuesto, pero también por otros entornos de ejecución como Deno, Bon, Electron y más. Y React Native para Windows ya usa esto en su bifurcación de Hermes. Así que si tú, como autor de una biblioteca, deseas admitir múltiples entornos de ejecución de JavaScript más allá de React Native, o ya tienes este enlace de Node API escrito, entonces no necesitas dedicar tiempo también a escribir y mantener un enlace JSI. Y ya existen muchos generadores de enlaces que exponen código nativo a través de llamadas de función generadas de Node API.

Y uno de mis favoritos personales aquí es que es trivial probar un enlace sin iniciar un simulador. Puedes simplemente ejecutar el proceso de Node.js con un dash dash test para ejecutar un proceso de Node.js consumiendo la biblioteca dinámica de Node API que construyes. Así que el ABI estable aquí, que es proporcionado por Node API, permite la distribución de tu biblioteca como un binario preconstruido. ¿Y qué significa esto? Bueno, es un gran beneficio para tus usuarios porque no necesitan esperar a que tu código se compile. Y también significa que no tendrán que experimentar y reportar errores de compilación nativa cuando cometas un error. Y también impone menos restricciones en su entorno ya que no tienen que lidiar con todas las elecciones que haces en torno a las herramientas que necesitas para construir tu biblioteca.

Entonces, ¿cómo logras esto? ¿Cómo preconstruyes y generas un enlace de Node API para tu biblioteca de Rust? Y de esto se trata la siguiente parte de mi presentación. Se trata de Ferric. Ferric es este envoltorio bastante simple alrededor de algunas otras herramientas. Y lo expliqué como siendo una parte, básicamente está compuesto de tres partes diferentes. Así que basado en macros de Rust con las que anotas tu código, esto genera un código de enlace de Node API de bajo nivel. Y este código básicamente llama a funciones de Node API por ti. Esto es proporcionado por NAPI-RS, el proyecto. Es un proyecto diferente que Ferric utiliza para lograr esto. Esto también genera declaraciones de TypeScript para tu biblioteca, que coinciden con la API de JavaScript resultante que se produce cuando se llaman estas funciones de Node API. En segundo lugar, la herramienta Ferric impulsará el compilador de Rust para construir bibliotecas dinámicas para cada una de las plataformas solicitadas y arquitecturas mientras estás preconstruyendo. Y finalmente, estas bibliotecas dinámicas se combinarán y empaquetarán en preconstrucciones, que son consumibles por React Native, Node API, y de lo que voy a hablar más adelante también. Estos son básicamente marcos XG cuando estás apuntando a Apple y directorios similares a JNI, Libs. Estos directorios donde tienes subdirectorios específicos de arquitectura y luego los archivos de objetos compartidos dentro de ellos cuando estás apuntando a Android.

Bien, es hora de una demo aquí. Construí esto llamado Rusty Web Storage. Es una implementación muy simple, pero básicamente envuelve esta API de almacenamiento, la API de almacenamiento local o de sesión proporcionada por un navegador web. Ahora queremos, como ejemplo, enviar esto para React Native. Y la forma en que lo hice es básicamente configurar un paquete aquí, Rusty Web Storage con un archivo package.json declarando la dependencia de la herramienta de construcción Ferric. También tiene un archivo Cargo.toml que establece la versión de Node API que utiliza. Declara que quiere compilar o construir como una biblioteca dinámica C, y también declara una dependencia de NAPI-RS, el crate que usamos para generar código. También tiene un conjunto de pruebas escrito contra el ejecutor de pruebas de Node.js, y tiene la implementación aquí en un archivo Rust.

El archivo Rust aquí es básicamente un poco de preámbulo. En este caso, solo tenemos esta estructura de almacenamiento. Es un hash map simple, así que todo está en memoria. Podría persistir, podría cifrar otras características. Podríamos agregar a esto, pero solo por simplicidad, solo estamos almacenando valores en un hash map. Y exponemos esto usando, en este caso, lo llamamos jsStorage. Y le damos un nombre diferente aquí. Cuando usamos la macro NAPI aquí, también proporcionamos un jsName para lo que se supone que debe ser el nombre cuando se genera el código JavaScript. Sí, así que internamente, tiene una referencia a este objeto de almacenamiento interno. La implementación de esto, nuevamente, la anotamos con la anotación NAPI aquí, o la macro.

Y aquí anotamos la nueva función como un constructor de NAPI. Sí, y es bastante simple. Luego implementamos los diferentes miembros esperados por la, o descritos en la especificación para el almacenamiento web. Aquí, una longitud para obtener todos los, como cuántos valores hay en el almacenamiento. Una función mutable aquí para básicamente limpiar el almacenamiento. Algo para obtener el elemento por clave. Algo aquí para obtener la clave de la enésima entrada en el almacenamiento. Esto se usa cuando generas sobre el almacenamiento. Luego hay algo aquí para eliminar una clave y finalmente para establecer una clave desde un, perdón, establecer un valor desde una clave. Bien, eso es todo. Y lo que haces entonces es básicamente ejecutar la herramienta de construcción Ferric aquí. Puedes ver que generamos para todos los diferentes objetivos.

Generamos las declaraciones de TypeScript. También generamos el punto de entrada. Es un archivo JavaScript. Construimos este directorio lib de Android. Y también combinamos algunas bibliotecas Darwin en una biblioteca universal. Y finalmente empaquetamos el marco NXE. Así que este es un comando que construye para Android y Apple desde el código Rust que acabas de ver. Y también genera el punto de entrada y las declaraciones de TypeScript.

Y aquí abajo, puedes ver debajo de la línea aquí, puedes ver todas las cosas que son artefactos de construcción efímeros. Primero el punto de entrada aquí, solo contiene una llamada require del nodo, el pre-construido que fue construido. Y el pre-construido aquí es solo una biblioteca dinámica regular construida para Node.js. Pero como un archivo hermano para que tengamos el Android.node aquí en los pre-construidos de Android, las cosas que están dirigidas a Android. Así que aquí es donde se colocarán los archivos de objeto compartido destinados a Android y las arquitecturas específicas de Android.

Y luego también tenemos este marco XG renombrado para iOS y macOS y otros como el simulador y lo que sea que esté pre-construido aquí. Bien, así que el punto de entrada es bastante simple. Es solo esta llamada require y la parte DTS aquí, el archivo de declaración de TypeScript. Puedes ver aquí, básicamente genera una clase, una clase de almacenamiento con un constructor y la propiedad length y o el getter aquí y luego todas las diferentes funciones que esperarías. Así que esto coincide con la especificación web. Y esto se genera completamente desde el código rush. También mencioné este archivo de prueba aquí que está escrito contra la API del ejecutor de pruebas de Node.js.

Aquí puedes ver que simplemente estamos importando el storage de nuestro paquete. Y esperamos que exporte una función como una función constructora aquí. Se puede construir. Puede establecer y obtener valores. Puede devolver null si falta una clave. Así que estas son como pruebas que podemos ejecutar. Tiene una longitud. Puede borrar todos los valores. Todas estas cosas son pruebas que podemos ejecutar en Node.js para ejercitar el módulo que creamos. Y también construí una aplicación de prueba en este caso. Esta es una aplicación Expo que consume este rusty web storage.

Y puedes ver aquí, hay una grabación de pantalla en el lado derecho de mí escribiendo y usando esta biblioteca. Básicamente, solo la estoy importando, inicializándola. Y luego aquí hay algo de gestión de estado alrededor de las pulsaciones de teclas. Entrada de texto aquí. Puedes ver aquí en el handle submit, hacemos storage set item, que es parte de la API que acabamos de implementar. Y puedes ver que tenemos un clear, el storage clear aquí cuando borras los elementos cuando presionas el botón aquí también. Y luego tenemos una iteración, como una forma de iterar sobre todos los valores posibles dentro del storage. Y también usamos el storage. Aquí, puedes ver que usamos la clave, la clave final, y también obtenemos el elemento basado en eso. Y luego también tenemos este código aquí donde eliminamos un elemento cuando haces clic en un icono de papelera a la derecha del valor.

Bien, como desarrollador de aplicaciones, lo que necesitas hacer para consumir esto, necesitas instalar el paquete React Native Node API modules. Y voy a entrar en eso. Y luego instalas la biblioteca. Luego haces pod install, o construyes tu proyecto Gradle. Y tienes que agregar un plugin de Babel a tu archivo de configuración de Babel. También voy a explicar por qué se necesita eso. Y finalmente, consumes el paquete como lo desees. Bien, entonces, ¿por qué necesitas esas cosas? Es porque hasta ahora he estado hablando de Ferric, pero como si React Native ya supiera cómo cargar Node API modules. Y esto, sin embargo, no es el caso.

Una parte importante del propietario de Fabric, perdón, no Fabric, Ferric siendo tan simple es el hecho de que la comunidad está trabajando en llevar módulos de Node API a React Native. Y esto es exactamente de lo que voy a hablar ahora. En el centro de todo de estos módulos de React Native Node API, tenemos este paquete host, lo llamamos. Lo llamamos host porque aloja los módulos de Node API. Viene con un Node API débil preconstruido para que las bibliotecas se vinculen contra él al preconstruirse ellas mismas. Y descarga una versión especial de Hermes con soporte para Node API. Descubre automáticamente y vincula estos enlaces de Node API, y coincide, que coinciden con esta especificación preconstruida, las gni-libs y los marcos XG de los que hablé antes. Y también, todo este paquete implementa un turbo módulo con una función requireNodeAddOn responsable de cargar las bibliotecas dinámicas preconstruidas y proporcionar las funciones de Node API a estos módulos. Y también inicializa un por módulo por tiempo de ejecución JSI, entorno Node API, también conocido como el nappyenv. Y finalmente, el paquete host exporta este plugin de Babel, que los desarrolladores de aplicaciones usan para transformar llamadas require para archivos .node en llamadas requireNodeAddOn.

Ahora veamos la secuencia de llamadas al cargar e inicializar y llamar a nuestra biblioteca Rusty web storage construida como un módulo de Node API. La aplicación requiere el preconstruido, que se registra e inicializa a sí mismo usando Node API, que la aplicación puede llamar, después de lo cual la aplicación puede llamar a la función getItem, que llama directamente a la biblioteca usando convenciones de llamada de Node API. Y nota cómo el FFI ahora se ha invertido en comparación con el puenteo manual en C. Ya no hay una biblioteca. Ya no es la biblioteca proporcionando la API de C. Ahora está consumiendo el Node API en su lugar. Así que el puente C ahora es genérico. Y esto significa que los nombres y conceptos ya no son específicos al dominio de la biblioteca. Y esto es enorme porque podemos invertir en hacer esto súper bien implementado y probado de una vez por todas.

Entonces, ¿cuáles son las limitaciones aquí? Mencioné al principio que esto es temprano y hay algunas limitaciones que se aplican. Mientras grabo esto, solo algunas de las funciones específicas de tiempo de ejecución de Node API están implementadas. Toda la manipulación de objetos y funciones de JavaScript funciona, pero el código asincrónico como futuros y promesas, no. Y el soporte de Hermes para Node API es un PR abierto, en el que se está trabajando activamente, pero aún no se ha fusionado. Esto significa que el tiempo de construcción inicial de la aplicación será lento porque básicamente estás compilando Hermes y React Native desde la fuente, y hay requisitos muy específicos sobre la versión de React Native que puedes usar. Y si piensas que algo de esto es interesante, por favor háznoslo saber y deja que otras personas también lo escuchen, porque necesitamos tu ayuda para mantener el impulso aquí. OK, no estoy solo en esto. Nada de esto sería posible sin la ayuda y la participación activa de nuestra increíble comunidad. Aquí hay algunos nombres de personas con las que me he estado reuniendo semanalmente desde enero, y probablemente también olvide mencionar a algunos, pero también me encantaría extender mi gratitud a mi empleador, MongoDB, y también al equipo de Callstack. Muchas gracias por su tiempo y atención. Es una mercancía rara estos días, y espero verte en persona. Por favor, detente y dime si encuentras algo de esto interesante, si me encuentras en persona. Adiós.