La ontología de Tauri
El mapa mental del territorio: la ventana y la webview del sistema, el puente hacia Rust, el modelo de permisos, el disco del usuario, la distribución firmada y el ecosistema de plugins.
El territorio, de un vistazo
Las ideas clave
Los dos procesos, y quién manda
La confusión más común al empezar es pensar que una app de Tauri es una página web con superpoderes. No lo es. Son dos mundos con vidas distintas, y el que manda no es el que ves.
El proceso core es el dueño: crea la ventana, arranca la webview, mantiene el estado y es el único que toca el sistema. La webview es un inquilino sin llaves —no tiene acceso al disco, ni a la red arbitraria, ni a un proceso hijo— salvo lo que el core le conceda explícitamente. Esa asimetría es intencionada, y es la diferencia de fondo con un navegador: en una pestaña el JavaScript es el protagonista; aquí es la capa de presentación de un programa que vive en otro sitio.
Cuánto de esto no es Tauri
Merece la pena hacer el recuento explícito, porque cambia cómo se estudia el track.
| bloque | qué es de Tauri | qué es de la plataforma |
|---|---|---|
| Armazón | la configuración, el CLI, la abstracción de ventana | el gestor de ventanas, el bucle de eventos, el hilo de interfaz |
| Puente | invoke, los comandos, los bindings generados |
la serialización, el coste de cruzar una frontera de proceso |
| Seguridad | permisos, capabilities, ámbitos | el modelo de permisos del sistema, el sandbox, la superficie del webview |
| Disco | los ayudantes de rutas, el plugin de ficheros | dónde escribe cada sistema, SQLite, las migraciones |
| Secretos | un plugin de cien líneas | Keychain, Credential Manager, Secret Service |
| Salida | el empaquetador y el updater | firma, notarización, Gatekeeper, SmartScreen, formatos de paquete |
La columna de la derecha es la que no caduca. Si mañana cambias a otro framework —o escribes el tuyo— esa columna viaja contigo entera. Por eso este temario apunta a seis conceptos del núcleo del centro de estudios (el bucle de eventos, la comunicación entre procesos, el escritorio como plataforma, la firma y cadena de confianza, los almacenes de secretos y SQLite) en vez de encerrarlos aquí dentro.
Cómo está ordenado el camino
Las diecisiete fases del track no siguen el orden de la documentación oficial, sino el orden en el que las cosas se rompen:
Primero se entiende el modelo, porque sin él todo lo demás se memoriza. Después se aprende a sostener una aplicación que guarda datos ajenos, que es donde la seguridad deja de ser un capítulo y pasa a ser una restricción de diseño. Luego la integración con el escritorio, que es la parte divertida y la que menos problemas da. Y al final la publicación, que es donde de verdad mueren los proyectos.