RLS, SSR y file-based routing
Tres conceptos técnicos que vas a ver en casi cada módulo del curso. Los vemos de corrido, en treinta segundos cada uno, para que al aparecer ya sepas dónde encajan.
[[rls|RLS]] aísla datos por usuario, [[ssr|SSR]] genera HTML en el servidor, [[file-based-routing|file-based routing]] convierte carpetas en URLs.
RLS — Row Level Security
Mecanismo de PostgreSQL (usado por Supabase) que filtra filas según políticas. Ejemplo: "un usuario solo puede leer sus propias invoices". La política vive en la DB, no en el código. Si olvidas aplicarla, cualquier cliente autenticado ve todo. Regla de seguridad #1 en Supabase: toda tabla tiene RLS activo desde el inicio.
SSR — Server Side Rendering
El HTML se genera en el servidor antes de llegar al navegador. SvelteKit lo hace por defecto. Ventaja: mejor SEO (Google lee HTML, no JS), primera pintura más rápida, datos sensibles no se exponen al cliente. Desventaja: lógica reactiva pura va en el cliente; cuidado con mezclar.
File-based routing
La estructura de carpetas define las URLs. src/routes/dashboard/+page.svelte → /dashboard. Sin config manual de rutas. Convención sobre configuración. Casi todos los frameworks modernos lo usan (SvelteKit, Next, Nuxt, Astro, Remix).
En tu próximo schema, ¿cuál es la policy RLS por defecto que aplicarías a toda tabla? Escríbela en una línea para tenerla lista como template.
- RLS = seguridad declarativa a nivel de fila en Postgres/Supabase.
- SSR = HTML generado en el servidor, ventaja para SEO y primera pintura.
- File-based routing = estructura de archivos = rutas, sin config.