studio

studio es una herramienta de desarrollo de escritorio que gestiona el trabajo con moodboards, cortes y sesiones - el tipo de trabajo en el que importa un acceso constante y rápido a los archivos del disco. Este caso de estudio trata sobre cómo construir una herramienta así de forma nativa sin multiplicar el código para cada sistema operativo.

La premisa era de dos caras. Por un lado, la herramienta debe sentirse como un programa nativo: archivos a mano, funcionamiento sin red, fluida incluso en una sesión grande. Por el otro, debe seguir siendo un solo repositorio y un solo núcleo, no tres aplicaciones separadas que luego haya que mantener tres veces.

Trabajar con moodboards y cortes significa echar mano de los discos constantemente: cientos de archivos, directorios de proyecto, vistas previas que deben aparecer al instante. Un navegador mantiene todo eso tras un muro de sandbox. Cada acceso a un archivo es un diálogo, sin red no hay aplicación, y en una sesión más grande la interfaz empieza a atragantarse.

Queríamos una herramienta que tuviera los archivos a mano como un programa nativo, funcionara sin red y no se ralentizara en una sesión grande. Pero sin la trampa en la que es fácil caer al escribir de forma nativa: código separado para Windows, macOS y Linux que luego se desvía entre plataformas y multiplica el trabajo en cada cambio.

Tauri da la vuelta a la disposición conocida de Electron. La interfaz la escribes una vez, en web, pero no cargas con todo un navegador - la ventana usa el motor de renderizado del sistema, mientras que todo el trabajo más pesado, el acceso a los archivos y la lógica se encuentran en un núcleo Rust. El resultado es un binario medido en megabytes, no en cientos de megabytes, y un acceso real al sistema que una página empaquetada nunca tuvo.

La diferencia no es cosmética. Electron entrega su propia copia del motor del navegador con cada aplicación, de modo que cada herramienta paga de nuevo por el mismo Chromium. Tauri usa lo que el sistema ya tiene y añade solo una fina capa propia. Para una herramienta que debe ser rápida y ligera, esa es la diferencia entre funciona y funciona al instante.

La división es limpia, y es ella la que mantiene a raya toda la arquitectura: la web dibuja, Rust hace. Las vistas de los moodboards y los cortes se escriben una vez, en web, mientras que las operaciones sobre archivos, la indexación y todo lo que debe ser rápido y sin conexión pasa por comandos Tauri hacia un núcleo que no sabe nada del aspecto.

El núcleo Rust es una biblioteca autónoma: carga de archivos, indexación, el modelo de sesión. No dependen de quién los dibuja, de modo que la misma lógica se puede probar sin interfaz y exponer por el mismo contrato en cada plataforma. La vista es una fina capa encima, y no el lugar donde vive el conocimiento sobre el proyecto.

La división limpia tiene una ventaja más: solo hay un lugar donde los errores hay que vigilarlos en serio. Dentro del núcleo confiamos en nuestros propios tipos - si una sesión está cargada, su modelo es válido. Pero una ruta de archivo que llega desde la vista es una entrada del exterior. Puede no existir, puede apuntar a un archivo corrupto, puede ser un resto de un proyecto movido.

Por eso la validación se encuentra exactamente en la frontera - en el comando Tauri - y no está esparcida por todo el núcleo por si acaso. Donde la web se encuentra con Rust, un error se convierte en un mensaje legible para el usuario; más adentro ya no tenemos que comprobar lo mismo una segunda vez.

La herramienta arranca rápido, tiene los archivos a mano y no necesita red para funcionar - y aun así no multiplica el código por sistema. Un repo, un núcleo Rust, una fina capa de vista encima y aplicaciones separadas a la salida, construidas desde la misma fuente.

Para la persona que la usa, eso significa que la herramienta se comporta como un programa nativo, y no como una página que finge ser una aplicación: señalas los archivos directamente desde el disco, el trabajo continúa sin red, y la interfaz no se atraganta en una sesión grande. Para el mantenimiento, significa que una nueva función añadida en el núcleo llega a las tres plataformas a la vez, en lugar de ser escrita y rota tres veces por separado.