Enlaces seguros para Node.js con Rust y WebAssembly

Hola a todos, y gracias a Node Congress por tenerme aquí. Esto es TypeScript Bindings para NodeJS con Rust y WebAssembly. Buscaremos un enfoque alternativo y más fácil para crear módulos nativos de NodeJS, al mismo tiempo que generamos automáticamente los tipos para ellos.

Un poco sobre mí. Soy Alberto Schibel. Soy de Venecia, Italia. Soy un ingeniero de software en Prisma donde he portado varios módulos de Rust a WebAssembly. También soy consultor y trabajo con NodeJS, TypeScript y Rust. Puedes encontrarme en línea en j.com.io. También puedes encontrar las diapositivas

Entonces, para nuestro primer ejemplo, veamos cómo podemos definir funciones de Rust que tomen un número, lo dupliquen y lo devuelvan al llamador. Sé que la sintaxis de Rust puede ser abrumadora, así que ten paciencia. Primero importamos la biblioteca wasm.bindgen. Luego le decimos a Rust que genere enlaces para la función que sigue, que se compilará a WebAssembly. Y cada vez que veas un código con un hashtag y un corchete cuadrado, eso significa que es una macro de Rust, un tipo especial de función que se expande para generar código en tiempo de compilación. Definimos una función pública, duplicate underscore U64, que toma un entero de 64 bits asignado, lo multiplica por dos y lo devuelve. La otra función es similar, pero utiliza números de punto flotante en su lugar. Y wasm.bindgen genera la siguiente declaración de TypeScript que ves en la parte inferior. Vemos que los nombres de las funciones se conservan tal cual. Los números U64 se asignan a BigInt y los números F32 son simplemente números en TypeScript porque realmente no tienen un tipo dedicado.

¿Qué sucede cuando intentamos usar estas funciones en TypeScript? Bueno, si pasamos tipos compatibles con las declaraciones de TypeScript, funcionan como se espera en tiempo de ejecución. Pero si escapamos de las validaciones de TypeScript disfrazando una cadena como un número entero grande y llamamos a la función 'n to string' con eso, bueno, en ese caso obtendremos un error de sintaxis en tiempo de ejecución porque la función espera un número pero se está llamando con una cadena.

¿Qué sucede si necesitamos estructuras de datos más complejas? Aquí tienes un ejemplo con nuestra estructura 'scholars' que envuelve valores como números, caracteres o booleanos. Digamos que queremos una función que extraiga el valor de uno de los campos, a saber, la letra. Si tuviéramos que escribir manualmente los enlaces de TypeScript para esto, definiríamos escalares como un diccionario tipado que llamamos 'construct' en su lugar y escribiríamos el campo 'letter' como una cadena porque TypeScript realmente no distingue entre cadenas de un solo carácter y cadenas de varios caracteres. Sin embargo, esto no es lo que hace WasBindgen y esto es lo que obtiene, lo que crea y aunque los cuatro miembros de la estructura tienen los tipos que esperamos, en realidad obtenemos una definición de clase escalar, no un tipo de diccionario. Además, vemos algunos detalles internos que se filtran en el código generado y eso es principalmente el método 'free' que no toma ningún argumento y no devuelve ningún valor. Esto no es algo que hayamos escrito en nuestro tipo Rust. Esto es algo que hace WasBindgen. ¿También te das cuenta de que falta algo más? Bueno, esta clase no tiene un constructor, ¿cómo creamos instancias de ella desde Node.js? Bueno, podemos intentar llamar al constructor JS predeterminado y asignar los campos manualmente. También necesitamos especificar una implementación predeterminada para este método 'free'. Sin embargo, si hacemos esto y pasamos una instancia de la clase Scalar a la función 'get letter', bueno, esto fallará en tiempo de ejecución con un error críptico: 'NullPointerPassToRust'. Resulta que podemos solucionar esto definiendo manualmente un constructor en Rust que tome los cuatro miembros de la estructura como argumentos utilizando la macro constructor y llamando al constructor desde TypeScript. Está claro que esta no es la mejor experiencia que podemos obtener, ¿verdad? Requiere código de plantilla y no es ergonómico para los desarrolladores de TypeScript. Por cierto, observa que el campo 'letter' se trunca automáticamente a una cadena de un solo carácter, aunque lo inicialicemos con una cadena más larga. Y ¿qué sucede si envolvemos cadenas en una estructura, de manera similar a como lo hicimos con los estudiosos? Este código no se compilará. Eso se debe a que las cadenas en Rust no se pueden copiar y WasBindgen necesitará copiar cadenas. Y una forma de solucionar el problema es hacer que WasBindgen clone la cadena con un atributo de macro dedicado, 'getter with clone', pero esto no es algo de lo que un desarrollador de TypeScript deba preocuparse. Es un detalle interno del que no necesitamos ser conscientes. Aún así, obtenemos un enlace de clase en lugar de un tipo de diccionario y hemos visto lo engorroso y torpe que es de usar. ¿Qué hay de las enumeraciones? Mientras que las enumeraciones de estilo C se traducen uno a uno a enumeraciones de TypeScript, por lo que podemos ver que WasBindgen funciona sin problemas en este caso. Sin embargo, las enumeraciones a menudo se consideran una mala práctica en la comunidad de TypeScript, ya que son un poco difíciles de razonar debido a que el tiempo de ejecución de JavaScript no tiene noción de enumeraciones, ¿verdad? Por lo tanto, eso podría llevar a errores inesperados. Idealmente, preferiríamos obtener una unión de tipos literales, como la que vemos en la parte superior derecha. ¿Qué hay de las uniones discriminadas, o uniones objetivo? Son un patrón popular en TypeScript, especialmente cuando se codifican tipos de datos algebraicos. Y resulta que Rust las admite en forma de variantes de enumeración. En este ejemplo, tenemos el tipo 'Either' que en un momento dado codifica un resultado numérico exitoso, con un constructor 'Ok', o un mensaje de error, con un constructor 'Error'. Sin embargo, las variantes de enumeración no son compatibles con WasBindgen, como nos indica el mensaje de error del compilador, por lo que no podemos usarlas tal como están.

Finalmente, WasBindgen proporciona soporte parcial para vectores homogéneos, pero solo para tipos numéricos, que se traducen a instancias de matrices tipadas. Y son esencialmente útiles solo cuando se manipulan datos binarios en bruto. Están bastante lejos de las matrices de propósito general estándar que normalmente deseamos. Además, los vectores de tipos no primitivos, vectores anidados o tuplas no son compatibles en absoluto. Entonces, WasBindgen proporciona las herramientas básicas para portar bibliotecas de Rust a Node.js. Pero no es ergonómico ni ideal para los desarrolladores de TypeScript y en general es bastante limitado. ¿Podemos hacerlo mejor que esto?

Bueno, la primera biblioteca no estándar que todo desarrollador de Rust suele encontrar es Serde, que proporciona macros y utilidades para serializar y deserializar tipos comunes de Rust en varios formatos con un mínimo de código repetitivo. Un primer paso para admitir más tipos de datos de Rust en JavaScript es exponer funciones que consuman y devuelvan cadenas codificadas en JSON, que luego podemos analizar y convertir en cadenas en Rust a través de los rasgos de serialización y deserialización de Serde. También he enumerado las dependencias que necesitamos agregar a nuestro archivo cargo.toml y nuestras versiones para la conveniencia de todos. Así es como funcionaría. Primero importamos Serde, luego lo aplicamos a una estructura o enumeración de Rust para que se vuelva automáticamente serializable y deserializable. Piensa en esos rasgos como interfaces necesarias para traducir estructuras de datos a formatos como JSON, y piensa en la macro derive como algo que implementa esos rasgos por nosotros. Luego definimos una función pública de cadena a cadena con la macro WasmBindgen que ya hemos usado. Luego analizamos la cadena de entrada que asumimos que está codificada en JSON en la estructura de estudiosos que definimos anteriormente. Calculamos el resultado y lo serializamos de nuevo a JSON. Y luego lo devolvemos al llamador. Observa que el enlace de TypeScript está técnicamente tipificado, pero no es muy útil, ya que podríamos pasar cualquier JSON o incluso una cadena que no sea JSON en absoluto y TypeScript aún lo aceptará en tiempo de compilación, aunque resultará en un error en tiempo de ejecución. La serialización JSON puede ser costosa en la práctica, por lo que SerDeWasmBindingCrate propuso un enfoque más eficiente que proporciona una integración binaria nativa de SerDe con WasmBinding. Por cierto, el proyecto es mantenido actualmente por CloudFlare y nuevamente, dado que se basa en Serde, obtenemos soporte para muchos otros tipos que podemos usar en JavaScript. Las diferencias notables con el enfoque básico de WasmBinding son que las variantes de enumeración se pueden traducir a uniones etiquetadas. Obtenemos soporte para generar vectores y también soporte para mapas.

De manera similar al ejemplo anterior, podemos definir una estructura escalar. En realidad, esto es un subconjunto del ejemplo. Podemos exponer una función pública que tome el valor escalar como entrada y devuelva su campo de letra a WasmBinding. Sin embargo, observa que esta vez los argumentos de Rust están tipificados como valor js, que modela cualquier valor que se pueda pasar o recibir de JavaScript. Luego depende de nosotros convertir estos valores js en tipos reales. Y lo haremos usando la utilidad Std WasmBinds from value y luego podemos convertir este resultado nuevamente en un valor js. Y sin entrar en demasiados detalles, vemos que la firma de la función nos dice que el resultado es un valor js o un tipo de error específico proporcionado por Std WasmBinds. Específicamente, es un WasmError. Sin embargo, si usamos este enfoque, perdemos por completo la seguridad de tipos, ya que el valor js puede

Como demostración, adaptaremos el ejemplo anterior utilizando variantes de Enum, que queríamos que se tradujeran a uniones objetivo en TypeScript. Entonces, vemos que necesitamos derivar los rasgos de SerDes, así como el nuevo rasgo de tspy. También necesitamos usar una nueva macro de tspy para indicar a Wasp bind que compile algunos tipos de datos, ya sabes, un tipo de datos que de otra manera no sería compatible con Wasp binding. De hecho, Wasp ABI significa Interfaz Binaria de Aplicación WebAssembly y describe cómo llamar a funciones entre lenguajes en WebAssembly. Luego definimos la variante either familiar con un giro que es común a todos los enfoques que usan SerDe. Necesitamos decirle a Rust cómo serializar esto en una variante porque, ya sabes, esto podría suceder de muchas maneras y para obtener uniones de etiquetas idiomáticas como las que vemos a la derecha, tenemos que decirle a Rust que el nombre de la variante debe asociarse con su clave dominante, es decir, la etiqueta de guion bajo, y que el contenido de la variante, que se define entre los paréntesis del constructor, debe asociarse a una propiedad llamada valor. Luego podemos definir una función que, por ejemplo, tome una instancia de either y devuelva su representación en cadena. Observa que realmente no requiere que escribamos ningún código de plantilla de conversión de tipos y se traduce en una definición limpia de TypeScript. Al igual que SerD vs BindGen, podemos definir un valor either en JavaScript sin necesidad de ningún constructor. Simplemente podemos crearlo en el momento como un diccionario. Pero esta vez obtenemos garantías de TypeScript, por lo que podemos aprovechar el compilador de TypeScript para evitar escribir errores tipográficos en nuestros tipos de datos. Así que resumamos lo que hemos aprendido hasta ahora. WebAssembly está aquí para quedarse, y es bueno para tareas intensivas de CPU que de lo contrario serían demasiado lentas en JavaScript puro, o para trasladar lógica compleja ya existente a la web. Piensa en Figma. Sin embargo, actualmente proporciona casi ningún soporte de entrada-salida. Entonces, si necesitas interactuar con el mundo exterior desde tus funciones, es mejor que te quedes con NAPI por el momento. Hemos iterado a través de varios enfoques para portar funciones de Rust a Node.js, y hemos observado que hay limitaciones o una experiencia de desarrollo incómoda, especialmente para aplicaciones de TypeScript. Finalmente, hemos visto que la mejor solución para enlaces seguros de tipos, TSFI, todavía es relativamente nueva. Una advertencia es que su código fuente depende en gran medida de la magia de macros, ¿verdad? Y eso podría ser un obstáculo para alguien. Además, para cualquier conjunto de enfoques, y eso incluye TSFI, no puedes simplemente usar contenedores genéricos como vectores o mapas hash directamente en una función que enlaces a WebAssembly. En realidad, primero debes especificar el tipo genérico. Entonces, tienes que hacer, tienes que decir, un vector de cadenas y luego tienes que envolverlo en una estructura o variante de Enum que luego expones a SerDe a través de los rasgos serializados o deserializados y luego lo usas en tu función. Y si quieres ver un ejemplo de TSFI siendo utilizado en la práctica, puedes revisar una solicitud de extracción en línea que introdujo soporte de WebAssembly a Lira, un motor de búsqueda de texto completo escrito en TypeScript por Mikhail Eriva, que creo que también habló aquí en el Congreso de Node. Mikhail Eriva estaba bastante satisfecho con las mejoras de rendimiento. Y eso es todo por mi parte. Soy Bertos Ghebel, puedes encontrarme en Twitter y GitHub, también puedes encontrar material adicional y ejemplos de código para esta charla en mi repositorio, node-congress-2023. No dudes en hacer preguntas adicionales ahora mismo o más tarde en Twitter, y gracias por tu atención.