{"id":147,"date":"2026-02-07T16:29:55","date_gmt":"2026-02-07T20:29:55","guid":{"rendered":"https:\/\/juredev.com\/blog\/?p=147"},"modified":"2026-02-16T11:04:34","modified_gmt":"2026-02-16T15:04:34","slug":"full-stack-en-rust-estructurando-aplicaciones-con-leptos","status":"publish","type":"post","link":"https:\/\/juredev.com\/blog\/2026\/02\/full-stack-en-rust-estructurando-aplicaciones-con-leptos\/","title":{"rendered":"Arquitectura Full-Stack en Rust: Estructurando aplicaciones con Leptos sin morir en el intento"},"content":{"rendered":"\n

Si vienes del mundo de React, Next.js o Go, sabes que mantener la sincron\u00eda entre el frontend y el backend es una de las mayores fuentes de bugs. Rust, con el framework Leptos<\/a><\/strong>, propone una alternativa interesante: isomorfismo real<\/strong>. Un mismo lenguaje, tipos compartidos y una \u00fanica definici\u00f3n central de los datos y reglas del sistema.<\/p>\n\n\n\n

Esta filosof\u00eda no es nueva para quienes venimos de C#<\/strong><\/a>, donde compartir librer\u00edas de modelos entre el servidor y el cliente es una pr\u00e1ctica habitual para mantener la consistencia de los datos. Sin embargo, Leptos aplica este enfoque de forma especialmente natural al desarrollo web moderno, permitiendo que esa \u201cfuente \u00fanica de verdad\u201d se compile tanto en el binario del servidor como en el WebAssembly del navegador.<\/p>\n\n\n\n

El resultado es un modelo en el que los contratos entre frontend y backend se expresan directamente en el c\u00f3digo compartido, reduciendo la necesidad de definiciones externas y disminuyendo los errores derivados de desalineaciones entre capas.<\/p>\n\n\n\n

En este art\u00edculo vamos a ver c\u00f3mo estructurar una aplicaci\u00f3n full-stack en Leptos con una arquitectura clara, pensada para ser escalable y mantenible, usando un ejemplo did\u00e1ctico orientado a introducir los conceptos principales del framework.<\/p>\n\n\n\n

1. El Coraz\u00f3n: La Capa de Dominio (\/domain)<\/h2>\n\n\n\n

En Leptos, el dominio puede ser isom\u00f3rfico<\/strong>. Esto significa que el c\u00f3digo dentro de esta carpeta se compila tanto para el servidor (nativo) como para el cliente (WebAssembly).<\/p>\n\n\n\n

Aqu\u00ed definimos nuestros structs<\/strong> y enums<\/strong>. Al usar la crate validator<\/strong>, podemos expresar reglas de negocio en un solo lugar:<\/p>\n\n\n\n

\/\/ domain\/user.rs\n#[derive(Serialize, Deserialize, Validate)]\npub struct LoginCredentials {\n    #[validate(length(min = 3, message = \"Usuario debe tener al menos 3 caracteres\"))]\n    pub username: String,\n    #[validate(length(min = 6, message = \"Contrase\u00f1a debe tener al menos 6 caracteres\"))]\n    pub password: String,\n}<\/code><\/pre>\n\n\n\n
\u00bfPor qu\u00e9 esto es clave?<\/strong><\/h3>\n\n\n\n
Porque la misma validaci\u00f3n se ejecuta en el frontend antes de realizar la request, evitando llamadas innecesarias, y vuelve a ejecutarse en el backend como validaci\u00f3n final. Esto ayuda a reducir la duplicaci\u00f3n de reglas entre capas y a mantener la consistencia del modelo.<\/p>\n\n\n\n
No elimina toda la l\u00f3gica espec\u00edfica de cada lado (por ejemplo, c\u00f3mo se muestran los errores en la UI), pero s\u00ed centraliza la definici\u00f3n de las reglas principales.<\/p>\n\n\n\n
Estado Global Tipado<\/h3>\n\n\n\n
Adem\u00e1s de las validaciones, el dominio tambi\u00e9n define el estado de autenticaci\u00f3n de forma expl\u00edcita:<\/p>\n\n\n\n
\/\/ domain\/state.rs\npub enum AuthState {\n    Loading,\n    Authenticated(User),\n    Unauthenticated,\n}<\/code><\/pre>\n\n\n\n
Este enum<\/strong> ayuda a evitar estados inv\u00e1lidos. No puedes representar un usuario autenticado sin datos, ni olvidarte de manejar el estado de carga. El compilador te obliga a ser exhaustivo, lo que reduce errores a medida que la aplicaci\u00f3n crece.<\/p>\n\n\n\n
2. La Fortaleza: El Servidor (\/server)<\/h2>\n\n\n\n
Aqu\u00ed reside la l\u00f3gica sensible: conexiones a bases de datos (SQLite\/SQLx), hashing de contrase\u00f1as (bcrypt) y gesti\u00f3n de sesiones.<\/p>\n\n\n\n
Gracias a las Server Functions<\/strong> de Leptos, no es necesario escribir una API REST manualmente. Simplemente defines una funci\u00f3n y Leptos se encarga del mecanismo de llamada entre cliente y servidor:<\/p>\n\n\n\n
#[server(Login, \"\/api\")]\npub async fn login(credentials: LoginCredentials) -> Result<User, ServerFnError> {\n    \/\/ Validaci\u00f3n en servidor (misma l\u00f3gica que el cliente)\n    validate(&credentials)?;\n    \n    \/\/ Consulta a la base de datos\n    let user = sqlx::query_as(\"SELECT * FROM users WHERE username = ?\")\n        .bind(&credentials.username)\n        .fetch_optional(pool)\n        .await?;\n    \n    \/\/ Verificaci\u00f3n con bcrypt\n    bcrypt::verify(&credentials.password, &user.password_hash)?;\n    \n    \/\/ Creaci\u00f3n de sesi\u00f3n con UUID\n    let session_id = Uuid::new_v4().to_string();\n    \n    \/\/ Cookie HttpOnly con SameSite=Lax\n    let cookie = Cookie::build((SESSION_COOKIE_NAME, session_id))\n        .http_only(true)\n        .same_site(SameSite::Lax)\n        .max_age(Duration::days(7))\n        .build();\n    \n    Ok(user)\n}<\/code><\/pre>\n\n\n\n
Este ejemplo est\u00e1 simplificado a prop\u00f3sito<\/strong> para ilustrar el flujo general. Detalles como persistencia avanzada de sesiones, manejo fino de errores o protecciones adicionales se dejan fuera para mantener el foco en la arquitectura y en el modelo mental de Leptos.<\/p>\n\n\n\n
Seguridad por Defecto<\/h3>\n\n\n\n
Al usar la directiva [cfg(feature = \u00abssr\u00bb)]<\/em>, el c\u00f3digo del servidor solo se compila cuando la aplicaci\u00f3n se ejecuta en modo SSR. El resultado es que la l\u00f3gica sensible y las dependencias del backend no forman parte del bundle WebAssembly<\/strong> que se env\u00eda al navegador.<\/p>\n\n\n\n
Adem\u00e1s, la gesti\u00f3n de sesiones utiliza:<\/p>\n\n\n\n