SvelteKit Full-Stack: Construye Aplicaciones Web Performantes con Server Actions

Esta ampliación usa Svelte5 con runes y el contrato de rutas/acciones de SvelteKit2 para acompañar el curso original. Comprueba package.json y el archivo de bloqueo antes de copiar ejemplos; las guías actuales también describen SvelteKit3 y funciones remotas. No mezcles una migración de versión con el ejercicio.

Este curso se organiza alrededor de una aplicación concreta: un tablero de tareas para un pequeño equipo que necesita consultar, modificar y coordinar trabajo sin convertir cada interacción en una API aislada. La ruta comienza en los fundamentos, porque una decisión de carpetas o de ejecución condiciona todo lo que vendrá después. Primero prepararás un proyecto SvelteKit, localizarás rutas y separarás componentes de página, y después construirás una interfaz inicial que pueda renderizarse antes de recibir interacción del navegador.

En el segundo módulo seguirás el recorrido de los datos. Una función load reunirá una lista de tareas antes de mostrarla, mientras una Server Action recibirá una mutación desde un formulario. La diferencia entre leer y escribir será una decisión explícita: las lecturas deberán ser reproducibles y las escrituras deberán validar entradas en el servidor. Practicarás también respuestas de error útiles, evitando que un mensaje de usuario o una caída de almacenamiento se mezclen con una excepción sin contexto. El formulario de contacto servirá como ensayo controlado antes de llevar estas decisiones al proyecto integrador.

El tercer módulo aborda el estado que cruza componentes y solicitudes. Un store puede representar una preferencia visible en varias zonas, pero no debe convertirse en una copia insegura de la sesión. La autenticación se modelará mediante una cookie que identifica una sesión mantenida en el servidor, con comprobaciones de autorización antes de mostrar o cambiar datos. Después compararás code splitting y caché desde una perspectiva medible: qué recurso se carga inicialmente, qué respuesta puede reutilizarse y cuándo una política demasiado amplia serviría información antigua o privada. El ejercicio de perfil reunirá estas piezas en una ruta protegida.

El último módulo convierte el aprendizaje en un sistema verificable. Definirás una estructura de tareas con identificadores, propietario, título, estado y fechas; decidirás qué operaciones forman el CRUD y establecerás reglas para cada una. Las actualizaciones en tiempo real no sustituirán a la persistencia: una Server Action confirmará primero el cambio y un canal WebSocket notificará después a los clientes autorizados. También tendrás que considerar mensajes repetidos, desconexiones y estados de carga, en lugar de suponer que la red siempre responde en orden.

El trabajo final será un tablero con lista, detalle, creación, edición, finalización y eliminación de tareas, limitado a la sesión del usuario. Incluirá una carga inicial, acciones validadas, almacenamiento persistente o, durante las primeras prácticas, un adaptador local explícitamente efímero, una sesión protegida y sincronización en tiempo real simulada o ejecutada en un entorno autorizado. No se evaluará una apariencia concreta, sino la relación entre requisitos, datos, rutas y respuestas.

Comprobarás el resultado con una matriz de casos: entrada válida, título vacío, tarea inexistente, usuario no autorizado, doble envío, cliente desconectado y dos clientes observando el mismo cambio. Cada caso debe indicar entrada, respuesta esperada y evidencia observable. El proyecto estará listo cuando otra persona pueda reproducir esas pruebas, inspeccionar que los secretos no llegan al navegador y explicar por qué cada dato vive en el servidor, en el store o en la interfaz.

Separa dos modos de entrega: una demostración local con repositorio en memoria pierde sus datos al reiniciar; el proyecto final persistente debe comprobar recuperación tras reinicio. Para dos pestañas del mismo usuario, la autorización por propietario basta; colaborar entre personas exige membresía de equipo validada en el servidor. Un roomId enviado por el navegador no otorga esa membresía. El canal WebSocket depende del servidor/adaptador o de un servicio separado: crear una ruta HTTP no instala por sí mismo un manejador de upgrade. Versiona los eventos, vuelve a cargar al reconectar y registra una publicación pendiente si el aviso falla después de confirmar la escritura.