Los dos mundos
El modelo mental que hace que todo lo demás encaje: qué vive en el proceso core, qué vive en la webview, qué cruza entre ellos y —lo más importante— qué no cruza sin que alguien lo autorice.
El mapa
La caja roja es la lección. Todo lo que hay ahí sí se puede hacer, y se hará: es de lo que tratan las fases V a IX. Lo que no se puede es hacerlo desde el frontend sin que alguien haya escrito un comando y haya declarado un permiso. Esa asimetría es el framework entero.
Cómo se lee «autoridad»
Conviene precisar la palabra, porque suena a metáfora y es literal.
El proceso core arranca con los permisos del usuario que ejecutó la aplicación. Puede leer su disco, abrir sockets, lanzar programas. La webview arranca dentro del sandbox del motor de navegador, que es el mismo sandbox de una pestaña: sin acceso al sistema de ficheros, con la política de origen aplicada, y sin más superficie que la que el anfitrión le añada.
Tauri añade exactamente una superficie: un canal de mensajes. Todo lo que el frontend puede hacer de más se hace por ahí, y por ahí solo pasa lo que hayas registrado. No hay una puerta trasera ni un modo relajado; hay comandos.
La pregunta que resuelve casi todo
Cuando no sepas dónde poner algo, hazte esta pregunta: ¿el frontend tiene derecho a decidir esto?
| lo que quieres hacer | dónde va | por qué |
|---|---|---|
| Leer un fichero de configuración al arrancar | core | El frontend no debería saber la ruta ni poder leerla. |
| Guardar el tamaño de la ventana | core | La ventana es del core. |
| Recordar qué pestaña estaba abierta en la interfaz | webview | Es estado de presentación, no del programa. |
| Llamar a una API con un token | core | El token no debe llegar al frontend. Nivel 48. |
| Formatear una fecha para mostrarla | webview | No tiene consecuencias. |
| Indexar diez mil ficheros | core | Trabajo pesado, y toca el disco. |
| Decidir qué mostrar mientras se indexa | webview | Presentación. |
| Cifrar antes de guardar | core | Donde está la clave, y donde está el llavero. |
La regla que resume la tabla: si tiene consecuencias fuera de la pantalla, va en el core. Si solo cambia lo que se ve, va en la webview.
El error que se comete siempre
Es este, y merece un aviso porque cuesta caro deshacerlo:
// MAL: un comando genérico que hace lo que le pidan.await invoke('leer_fichero', { ruta: rutaQueVieneDeLaInterfaz });Un comando así traslada la autoridad del core al frontend. Da igual lo bien escrita que esté la capability: cualquiera que consiga ejecutar JavaScript en tu webview —una dependencia comprometida, un contenido remoto, una inyección— puede leer el disco entero.
La forma correcta expresa la operación, no el mecanismo:
// BIEN: el core sabe qué fichero es y por qué; el frontend solo pide la acción.await invoke('cargar_proyecto', { id: proyectoId });Ahora el core valida el identificador, resuelve la ruta él mismo dentro de su propio directorio, y devuelve datos. El frontend no puede pedir nada que el core no haya previsto. La fase V vuelve sobre esto con nombre propio, pero la disciplina empieza aquí, en el nivel 4, mucho antes de escribir la primera capability.