Un Tipo Diferente de Serverless: Un Estudio de Caso para SQLite y Whisper.cpp

Hola a todos, hoy voy a hablar sobre un tipo diferente de serverless. Este es un estudio de caso para SQLite y whisper.cpp ejecutándose puramente en el navegador. Así que básicamente, construí una aplicación. Quiero guiarte un poco sobre cómo construí esa aplicación, cómo funciona un poco bajo el capó, y un poco de la tecnología que utilicé.

Pero también, voy a tener que explicar qué es realmente Wasm, porque así es como podemos hacer todo esto. Así que, comencemos. Pero primero, un poco sobre mí. Soy un defensor de desarrolladores en GitKraken. Es mi primera vez en este tipo de rol, y realmente lo estoy disfrutando. He sido ingeniero durante unos 10 años, y es bastante divertido. Soy un streamer de Twitch y un YouTuber perezoso. Además de un entusiasta de los gorros. Tengo muchos gorros. Si quieres encontrarme en otras redes sociales, mi nombre es CMGriffin en básicamente todas las plataformas. Puedes usar este código QR para encontrarme también, y ya sabes, sí, conectémonos. Vamos a charlar. Pero ahora, vamos a profundizar en ello.

¿Qué es Wasm? Entonces, Wasm es WebAssembly. Es un estándar abierto, y su objetivo es soportar cualquier lenguaje en cualquier sistema operativo. La idea es que, si puedes compilar desde un lenguaje como Rust o C++ o Go o lo que sea, puedes ejecutarlo en tu navegador como Wasm, y tienes esta gran portabilidad. Así que, sí. Wasm. ¿Qué? Aquí hay una representación técnica o textual de cómo se ve Wasm. Y no necesitas memorizar esto, pero imaginemos este programa que está construido de estas, ya sabes, expresiones S. Cuando se compila a Wasm, se convierte en este formato binario. Así que, este es ese mismo programa exacto. Ahora, no vas a necesitar memorizar esto, pero podemos revisar y ver qué son algunas de estas cosas. Así que, esa primera línea identifica esto como WebAssembly, como un binario de WebAssembly, como cosas de Wasm, así como la versión de Wasm que estamos soportando. Va a haber la definición del módulo. Están los tipos de los parámetros, el número de tipos que estamos pasando, ya sabes, la función que estamos exportando, ya sabes, el número de resultados que devolveremos, y el tipo de ese resultado de retorno.

Está la firma de la función, ¿verdad? Entonces, esos son los argumentos que la función toma, el tamaño de la misma, el número de funciones que estamos exportando. {{^}}Está la sección de exportación, que es la palabra clave export, el tamaño de esa sección, el número de exportaciones. Y a medida que seguimos, está la sección de exportación, que es solo un poco más como el nombre de la exportación, ya sabes, la sección de la función, que es en realidad como el código dentro de ella, la lógica de esa sección y cómo estamos manipulando algunas de las variables que se pasan a ella, y finalmente el final, que denota como el final de ese bloque binario. Y realmente, de nuevo, no vas a necesitar memorizar esto, pero sigue siendo algo interesante, y si quieres leer más al respecto, puedes encontrar la especificación binaria en GitHub.

Así que ahora, consideremos realmente la historia de Wasm. Comenzó en 2011, que es hace mucho tiempo, antes de que yo fuera realmente un desarrollador. Podías usar Emscripten para compilar C y C++ desde 2011 a algo que se ejecutaría en el navegador. Google tenía su propia versión de algo similar a Wasm llamado Native Client, o NACL, y luego en 2013, se introdujo ASM.js, y ASM.js era código JavaScript que luego se pasaría a este compilador ASM.js para que el navegador lo optimizara y ejecutara, y era muy interesante, porque escribirías código JavaScript, pero anotarías tal vez el tipo de una cierta variable para hacerle saber que sería un float o un entero o cosas así. Y luego en 2015, Wasm en sí fue anunciado, ese formato binario real. NACL fue luego deprecado un par de años después a favor de Wasm, porque Google decidió que, sí, ¿por qué construir algo y mantenerlo ellos mismos cuando podrían realmente apoyar un estándar abierto? El soporte amplio de navegadores llegó alrededor de ese mismo tiempo. Después de eso, obtuvimos algo llamado Wasi, que es la interfaz del sistema WebAssembly, que explicaré un poco más aquí en un momento. En 2019, los hilos de Wasm se habilitaron por defecto en Chrome, y en 2022, Wasm 2.0, un borrador para ello fue creado. Hay un poco de controversia alrededor de ese borrador y cómo funciona, pero no vamos a profundizar demasiado en eso ahora mismo. Puede que valga la pena leerlo por tu cuenta.

Así que Wasi es la interfaz del sistema WebAssembly. Está diseñado por Mozilla, y proporciona un conjunto de características similares a POSIX, por lo que puedes obtener como entrada/salida de archivos o redes o cosas que tu sistema operativo maneja por ti que cuando compilas un binario para un cierto sistema operativo, esos son los enlaces que realmente están siendo conectados para ti a ese binario. Así que en su lugar, Wasi te ayuda a hacer eso con código Wasm, y cuando combinas esas cosas juntas, obtienes algo muy poderoso. Solomon Hikes, el creador de Docker, dijo una vez en 2019, si Wasm y Wasi existieran en 2008, no habríamos necesitado crear Docker. Así de importante es. WebAssembly en el servidor es el futuro de la computación. Solo piensa en eso, como realmente poderoso. Así que la portabilidad que obtendríamos para ejecutar Wasm en la Web también significaría que podríamos obtener esa portabilidad a nivel de servidor, y ya sabes, no necesitaríamos Docker en ese punto siempre y cuando haya una interfaz Wasi para exponer estas cosas para nosotros. Y siempre y cuando nuestras dependencias pudieran compilarse a Wasm también. Mi charla favorita y ejemplo de cómo podría ser este futuro es The Birth and Death of JavaScript por Gary Bernhardt. Ahora, el título es engañoso. No es realmente anti-JavaScript. Tiene algunos puntos muy buenos sobre cómo no es un lenguaje perfecto, por supuesto, porque no existe tal cosa. Pero él pasa por y señala que debido a que JavaScript es como es, llevó al futuro que estamos viendo donde la gente está presionando para que Wasm obtenga un código más eficiente de su navegador.

Y es muy entretenido. Tiene algo de sátira. Es mi charla de conferencia favorita de todos los tiempos. Recomiendo mucho verla. Y fue en 2014. Él como que vio lo que se avecinaba y el futuro que estamos experimentando ahora hace diez años, lo cual es increíble.

Así que si quieres escribir un lenguaje y compilarlo a Wasm y con suerte ejecutarlo en tu navegador o en algún runtime de servidor, ¿qué lenguajes podrías usar? Los principales son C y C++, Rust y Go. Pero hay lenguajes estables como C Sharp, Zig, Lua y muchos más. Si quieres ver la lista completa de su soporte variable y con qué lenguajes podrías ser capaz de hacer esto, adelante y revisa ese repo de AppCypher. Tiene esta lista increíble, y se mantiene bastante actualizada.

Así que ahora si quieres ejecutar Wasm, sí, quiero decir, todos los navegadores modernos lo soportan, como vimos en la línea de tiempo. Así que eso significa, sí, Chrome, Firefox, Opera, Safari, Edge, pero no Internet Explorer. Así que si tienes que soportar Internet Explorer todavía, no vas a estar usando Wasm. Esperemos que ninguno de nosotros tenga que hacer eso. Y si lo haces, bueno, lo siento. Mejora. Ahora si quieres ejecutar Wasm fuera del navegador, ¿cómo puedes hacer eso? Bueno, hay herramientas como Xtism, WasmTime, Spin, que es el Spin SDK, y Wasmer. Xtism es realmente genial porque es un sistema de plugins. Así que imagina que tienes un binario de Go, como Hugo, y quieres escribir algo de código Rust para extender eso. Puedes usar Xtism para crear ese ecosistema de plugins para ello. Wasmer es muy interesante porque pretende ser como un runtime estilo serverless donde simplemente le envías algo de Wasm, y se iniciará y ejecutará ese Wasm como si estuvieras enviando un contenedor Docker o algo así. Pero es más liviano. Y hay más runtimes, también. Se están añadiendo todo el tiempo. Este propietario del repo, AppCypher, tiene múltiples repos basados en Wasm, o repos enfocados en Wasm, que como que nos ayudan a descubrir y aprender más sobre ello. Así que increíble. Me encanta el código abierto. Es simplemente genial de esa manera. Pero piensa en esto. ¿Cuáles son algunas aplicaciones populares que están usando Wasm ahora mismo? Y puedes encontrarlas en madewithwebassembly.com, pero enumeremos algunas.

Así que la más importante, la primera, realmente, es Figma. En 2017 se dieron cuenta de que WebAssembly era el futuro, y comenzaron a construir hacia ello con su lienzo infinito. Así que el renderizado de ese lienzo infinito es Wasm. CapCut, que es un editor de video, su versión web del editor de video, utiliza Wasm. 1Password y Google Earth y uBlock Origin y Leachess también usan Wasm. 1Password y uBlock Origin lo están usando para búsquedas en sus bases de datos muy grandes de ya sea donde se almacenan tus contraseñas o qué anuncios podrían necesitar ser bloqueados, etc. Así que están acelerando eso con Wasm porque obtienen números reales en lugar de que todo sea de punto flotante. Obtienen estructuras de datos reales y acceso a memoria real en lugar de solo depender del recolector de basura. Así que es algo bastante genial.

Así que ahora, ¿verdad?, no todo es sol y arcoíris. Hay algunas limitaciones y preocupaciones. Algunas de las limitaciones de Wasm en el navegador significan que no obtienes acceso directo al DOM. Al menos no todavía. Y eso significa que necesitas una especie de shim de JavaScript para comunicarte entre el Wasm y, ya sabes, document.querySelector en el navegador como estamos acostumbrados. El uso de RAM podría ser mayor dependiendo de cómo funcionen las cosas, el tamaño de tu carga útil de Wasm y simplemente tener que serializar datos entre el hilo principal y un hilo de trabajo. Y en su mayor parte, en el navegador, debes ejecutarlo en un WebWorker.

Y ahí es donde entra ese costo de serialización. Ahora, fuera del navegador, hay acceso limitado al sistema. Con suerte, tienes un runtime WASI, ya sabes, soportado. Y eso resuelve ese problema para ti. Pero no todo tiene eso de serie todavía. Así que aún hay trabajo por hacer. Pero también hay preocupaciones de seguridad. Así que número uno, es un binario en lugar de JavaScript. Así que tenemos una vida muy privilegiada como desarrolladores web que cuando consumimos algún código JavaScript siempre que esté bien escrito, podemos leerlo y entenderlo y saber qué está haciendo. Así que no hay sorpresas en lo que está haciendo. Si vemos código JavaScript que está muy ofuscado, generalmente podemos asumir que está haciendo algo nefasto. Pero con los binarios, no podemos hacer esa suposición porque incluso el código Wasm realmente seguro podría parecer inseguro porque está ofuscado en un binario. Y luego los shared array buffers son otra preocupación importante para la seguridad.

Pero hoy en día, siempre que mantengamos un contexto seguro, es decir, HTTPS, y tengamos Corp invocado, así que Corp son políticas de recursos de origen cruzado. Siempre que tengamos eso, podemos obtener acceso a los shared array buffers y eso nos da una mejor manera de manejar los web workers para que no tengamos que serializar objetos de ida y vuelta entre el hilo principal y el web worker. Y cuando digo serializar, me refiero literalmente a usar json.parse y json.stringify para enviar estos mensajes de ida y vuelta. Eso es una gran cantidad de sobrecarga y los shared array buffers pueden ayudarnos a evitar eso.

Así que ahora voy a hablar sobre un ejemplo del mundo real. Comencé diciendo que este era un estudio de caso, hemos aprendido sobre Wasm, ahora hablemos sobre la aplicación que construí usando Wasm y algunas bibliotecas realmente geniales. La llamé Orderly. Y la idea básica es que quiero escribir libros, quiero escribir publicaciones de blog, pero no necesariamente quiero exacerbar el inminente túnel carpiano por tener que escribir un libro de 100,000 palabras o algo así. Así que en su lugar, quería poder dictar, ya sabes, mi prosa, mi libro en fragmentos y trozos y capítulos que luego podría exportar a un PDF o algo así en el futuro. Así que solo para ahorrarme todo el esfuerzo de escribir. Y además, no soy un mecanógrafo muy rápido. Así que en su lugar, puedo sortear eso con tecnología y Orderly es la herramienta que construí para eso.

Así que los objetivos principales, ¿verdad? Dictado por voz. Escribir libros, publicaciones de blog, etc. También quería que fuera barato porque, ya sabes, no estoy hecho de dinero. Quiero poder ejecutar esto en el navegador sin tener que pagar por un servidor para ejecutarlo todo el tiempo. Así que quería no tener servidor, y tampoco quería consumir algún tipo de software como servicio como PicoVoice o algunas de las otras herramientas de dictado en JavaScript que existen. Así que sí, tenía estas limitaciones, y había oído hablar de whisper.cpp antes, lo cual profundizaremos aquí en un segundo. Pensé, intentemos hacerlo realidad. Así que aquí está la arquitectura. Estoy usando React. Así que es React 18. Esto se hizo tal vez hace un año, así que no quería subirme al tren de React 19 todavía. Estoy usando Mantine para mis componentes de UI. Las partes interesantes y asombrosas son SQL local, que es SQLite en el navegador y whisper.cpp, en los que profundizaremos más aquí en un momento. Para la gestión de estado, estoy usando YoTi, porque me gusta la gestión de estado estilo atómico. Para exportar a un PDF, estoy usando PDF.js. Para fechas, Day.js. Hay un árbol, como un árbol estilo sistema de archivos, que se colapsa y expande a la izquierda de mi aplicación. Estoy usando React Arborist para eso.

Estoy usando Case para la conversión de mayúsculas y minúsculas de texto, porque no quiero tener que escribir esas conversiones de kebab case a camel case todo el tiempo y cosas así. Y finalmente, para un ORM para interactuar con SQL local, estoy usando Keasley y Drizzle. Y profundizaré en el porqué de eso aquí en un momento.

Así que primero, SQL local. Es SQL adecuado, o SQLite. Así que puedes ejecutar cualquier consulta de SQLite en el navegador usando SQL local. Es subprocesado, lo que significa que no vas a bloquear tu hilo principal, y se persiste a través de OPFS, que es el Origin Private File System, que es solo una cosa que los navegadores están implementando y que es más rápido que IndexedDB. Así que muy agradable, muy fácil de comenzar. Recomiendo echar un vistazo a SQL local.

Pero OPFS, creo, es la parte más interesante de implementar SQL local. Es parte de la API de acceso al sistema de archivos. Tiene soporte básico en todos los navegadores principales, desde finales de 2021. No es un sistema de archivos real, por lo que no está destinado a ser visible para los usuarios. De hecho, se representa en tu sistema de archivos local con los navegadores manteniéndolo pero no está destinado a que realmente puedas explorarlo y encontrar archivos en él. Así que no esperes poder buscar y copiar y pegar cosas desde tu sistema de archivos local. Es para que el navegador interactúe con él. No hay mensajes de permiso ni verificaciones de seguridad para él, porque está debidamente aislado. En lugar de darle a tu navegador acceso completo a todo tu sistema de archivos, el navegador se asegura de que no estés escapando para ir a manipular archivos del sistema o cosas que podrían ser potencialmente peligrosas para la seguridad. Tiene la misma cuota de almacenamiento del navegador que IndexedDB y el almacenamiento local, y puedes consultar eso para ver cuánto almacenamiento te queda. Y es utilizable desde el hilo principal o un web worker.

Y los web workers pueden realizar operaciones sincrónicas, lo que puede hacer que nuestro código sea un poco más fácil de razonar dentro del web worker en lugar del hilo principal, ¿verdad? Porque no tenemos que preocuparnos por pausar el hilo principal al realizar operaciones sincrónicas. Así que mencioné que estoy usando Keasley y Drizzle al mismo tiempo. ¿Por qué haría eso? Bueno, en realidad estoy usando Keasley para las migraciones y la configuración de las tablas, índices y la inicialización de la base de datos, el andamiaje o fixtures o como quieras llamarlo. Así que estoy haciendo todo eso con Keasley porque es un poco más fácil de esa manera. Con Drizzle, usan una herramienta CLI para generar las migraciones. Y como quería ejecutar todo esto en el navegador solo para el usuario, no quería crear una herramienta CLI para eso. No quería tener algún paso de construcción para generar estas migraciones. Solo quería ejecutar las sentencias SQL.

No es un ORM completo. Está hecho por el creador de Objection.js. Así que sabes que hay alguien detrás que tiene experiencia haciendo este tipo de cosas. Pero no hay magia. Es solo SQL, lo que significa que realmente no obtienes relaciones con él. Puedes configurar claves foráneas y todo eso, pero cuando haces una consulta para algo en Keasley, no vas a obtener los valores anidados, como los valores unidos de la misma manera. Aún puedes hacer esos joins y obtener esos datos, pero tendrás que escribir ese SQL a mano tú mismo. Mientras que Drizzle nos permite hacer algo de eso de una manera más fácil, como un ORM, de la manera que esperaríamos. Y es seguro en tipos, capaz de manejar relaciones, así que Drizzle es para las consultas, Keasley es para las migraciones.

Al construir mi aplicación, había un par de consideraciones clave que hacer. Necesitaba crear la idea de que la aplicación estuviera lista. Y que la aplicación esté lista es básicamente después de que mis migraciones y andamiaje se hayan ejecutado, porque no quiero que Yotai escupa un estado al usuario que va a estar inmediatamente obsoleto una vez que las cosas se hayan ejecutado, y tampoco quiero que la lógica de Yotai para obtener cosas de la tienda SQLite tenga que lidiar con esas tablas que no se han creado y hacer algo de magia con try catch y manejar eso. Así que, en su lugar, simplemente creé este estado de aplicación lista, y una vez que las migraciones se ejecutan, puedo simplemente establecer que la aplicación está lista a verdadero, y mi estado derivado de Yotai realmente se actualizará. También va a haber una necesidad de suspense, ¿verdad?

Como todo esto está sucediendo en tu navegador, ¿realmente necesitas preocuparte por el suspense? Bueno sí, para una buena experiencia de usuario, sí. Porque incluso guardar en el sistema de archivos privado de origen lleva tiempo. Y si estás escribiendo en algo como un campo de entrada controlado, incluso un poco de retraso en eso va a ser realmente notable para el usuario. Así que el suspense sigue siendo necesario, hay lectura y escritura asíncrona que puede causar demasiados momentos de carga, así que hice mucha magia de start transition con React. Y también vas a querer hacer cosas con UI optimista y la limitación de entradas para asegurarte de que no estás escribiendo en el sistema de archivos demasiado, ¿verdad? Podrías agrupar las cosas un poco mejor. Y la UI optimista también es agradable porque es instantánea en el hilo principal en lugar de tener que hacer un viaje de ida y vuelta al sistema de archivos y de regreso. Así que muchas de nuestras consideraciones basadas en el servidor para construir una aplicación del lado del navegador todavía realmente importan.

Y luego podemos pasar a whisper.cpp. Entonces, primero, ¿qué es Whisper? Whisper es un proyecto de código abierto, open AI escrito en Python y tiene un CLI o un SDK de Python que puedes usar. Es lo que realmente me permite grabar audio y tomar ese audio y extraer el texto de él para la dictado de mi aplicación.

Con Whisper, tenemos todos estos modelos, como los tiny, base, small y large. El modelo large termina siendo casi como un gigabyte, creo. Tendría que verificar el tamaño exacto del archivo, pero estas cosas pueden llegar a ser bastante grandes. Hay algunas versiones más pequeñas, pero en su mayor parte, sabes, tienes que estar consciente de qué modelo va a cargar alguien. Y los modelos más grandes funcionan más rápido, pero requieren mucho más VRAM o RAM del usuario. Así que permitirles elegir cuál era esencial para mi caso. Todavía estoy usando un Mac mini de 2014, así que tuve que usar los tiny o base solo porque, sabes, mi máquina no podía manejarlo.

Ahora whisper.cpp es en realidad una implementación en C, C++ sin dependencias. Así que Apple Silicon es de primera clase, obtienes AVX Intrinsic, así que cosas SIMD para x86. No hay asignaciones de memoria en tiempo de ejecución. Y hay soporte incluso solo para CPU, así que ni siquiera necesitas una GPU para ejecutarlo. Pero también hay soporte eficiente para GPU a través de WebGPU en navegadores que lo soportan. Y obtienes una API de estilo C agradable. Así que uno de los trucos para conectarlo es que se ejecuta dentro de este hilo wasm, y nosotros tenemos nuestra aplicación principal que necesita comunicarse con él.

Así que termino creando este script que maneja el paso de mensajes entre whisper y mi aplicación principal, y luego puedo simplemente escupir eso a donde lo necesito. Ahora la parte complicada es que tengo que crear este array de resultados recientes y tengo que usar expresiones regulares para entender qué mensajes están siendo pasados desde whisper. ¿Son solo los tiempos, dejándome saber cuánto tiempo tomó algo? ¿Fue un audio en blanco que realmente quiero ignorar? ¿O es realmente solo el texto que estoy buscando? Así que tengo esta función de impresión que es lo que whisper va a llamar desde el back end. La pruebo para algunas expresiones regulares y empujo los mensajes a ese array porque no me lo va a dar todo de una vez, va a transmitir fragmentos del texto mientras procesa el audio. Y luego finalmente cuando termina, puedo escupir ese resultado reciente a mi aplicación a través de solo un evento que he creado personalizado. La última cosa que fue un obstáculo para implementar fue el alojamiento.

Así que hablamos sobre OPFS y shared array buffers y cómo funcionan un poco. La dificultad está en cómo los implementamos. Así que con GitHub Pages intenté usarlo pero no tenemos acceso para configurar encabezados desde GitHub Pages, así que no pudimos obtener soporte para shared array buffer o OPFS de la caja. Ahora hay una posible solución usando CoI Service Worker o COI Service Worker. Y lo que hace es usar un service worker para interceptar tus solicitudes a tu JavaScript y HTML y CSS y todo eso para como, y el WASM también, para permitir que estos encabezados sean inyectados a nivel del service worker en lugar de desde el servidor. Pero hay un poco de inconsistencia debido a la carga y el orden de las operaciones con eso Decidí que simplemente tenía que hacer algo más. Así que en su lugar usé otro servicio.

Usé Render. Render nos permite hacer la configuración de encabezados. Es agradable y fácil. Se despliega desde un repositorio git. Así que eso también es agradable y fácil. Pero podría haber usado Netlify o Vercel o Cloudflare. Todo eso está totalmente bien.

Esto fue genial para la aplicación en sí, pero mencioné el modelo grande de un gigabyte. Alojar esos modelos es algo que no quieres hacer dentro de un Vercel o Netlify porque eso puede volverse realmente costoso. Así que en su lugar, solo encontré algún proveedor de VPS barato a través de low end box. Sabes, los modelos pueden volverse grandes. Obtengo un ancho de banda predecible. Así que obtengo un terabyte de transferencia de este VPS barato de $2 al mes. Puedo iniciar un servidor de archivos simple a través de caddy y puedo obtener cosas de SSL TLS, ¿verdad? HTTPS de ello con solo una línea de configuración con caddy. Así que por $2 al mes tengo un presupuesto predecible frente a cuánto podría costarme con uno de los proveedores más grandes y comunes.

Así que sé que eso fue un montón. Salté un poco. Pero creo que al menos has obtenido suficiente inspiración para comenzar a construir por tu cuenta algún tipo de aplicación que tal vez sea solo local primero, usando Wasm, haciendo cosas que ni siquiera pensabas posibles hace solo unos años. Gracias por permitirme hablar y que tengas un gran resto de tu día.