Por qué separamos el marketing del producto

Hoy lanzamos apps/marketing, un sitio estático en Astro que sirve la landing, el blog y el formulario de contacto. Antes todo eso vivía dentro de la app Angular del producto. Esto explica por qué hicimos el split y qué trade-offs aceptamos.

El problema

La app de Angular atendía dos audiencias muy distintas:

1. Visitantes anónimos que llegan a la landing, leen sobre el producto y quizás dejan un mensaje en el formulario de contacto.
2. Tenants autenticados que emiten facturas, notas, documentos soporte y revisan su dashboard.

El primer grupo solo necesita HTML y CSS. El segundo carga PrimeNG, Transloco, el cliente HTTP, el Auth service, el authInterceptor, el provideAppInitializer, los guards, los stores de signals, los layouts, el router con sus 30+ rutas. Para mostrar una sección de marketing estábamos descargando todo eso.

Lo que cambia

• apps/marketing (Astro 5) sirve /, /blog, /blog/[slug], /contacto. Es estático. No hay runtime de Angular. No hay JWT, no hay guards, no hay Transloco.
• apps/web (Angular) sirve /login, /home, /invoices, /notes, /customers, etc. Esto no cambia.
• El API en apps/api ya tenía el endpoint POST /api/contact (lo necesitamos para el formulario). El frontend ahora vive en apps/marketing pero el endpoint no se movió.
• La misma cookie de sesión funciona en ambos porque comparten dominio. Si vienes logueado del producto y refrescas la landing, no te desloguea.

Lo que no cambia

• La marca. Los tokens de diseño están duplicados entre las dos apps (mejor refactor a packages/ui después, fuera de scope).
• El dominio. La landing y el producto viven bajo el mismo dominio, ruteados por un reverse proxy por path.
• La autenticación. Una sola sesión para el usuario. El endpoint de refresh sigue en el API, igual que antes.

Trade-offs que aceptamos

• Cross-app navigation es un full page reload. La landing no conoce el bundle del producto, así que el link a /login recarga la página. Es la frontera correcta.
• Doble deploy. El sitio estático se publica a un CDN; el producto a su target habitual. Si querés cambiar la landing, redeployás solo marketing.
• El bundle de marketing ya no contiene dependencias de Angular. Eso es lo que queríamos. La landing pesa una fracción de lo que pesaba.

Próximo paso

El siguiente split es la app de admin del dueño de la SaaS (gestión de tenants, billing, soporte). Esa historia la contamos cuando la armemos.