WEBGAE
Contacto

Arquitecturas Híbridas: Combinando lo mejor de SPAs y MPAs

Por ximo

Arquitecturas Híbridas: Combinando lo mejor de SPAs y MPAs

La dicotomía entre Single Page Applications y Multi-Page Applications siempre fue una falsa elección. Las mejores aplicaciones web modernas no son puramente una u otra, sino arquitecturas híbridas que aplican el patrón correcto a cada parte de la aplicación. Los frameworks modernos como Next.js, Remix, SvelteKit y Nuxt están liderando esta evolución, permitiendo que los desarrolladores mezclen estrategias según las necesidades específicas de cada página o componente.

La evolución de Next.js: un caso de estudio

Next.js es quizás el ejemplo más ilustrativo de esta transición hacia arquitecturas híbridas. Su evolución muestra claramente el cambio de paradigma en el desarrollo web.

Pages Router: El enfoque tradicional (2016-2022)

El Pages Router original de Next.js ya era híbrido en cierto sentido:

// pages/blog/[slug].js
export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

// Static Site Generation - se genera en build time
export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);
  return { props: { post } };
}

// Define qué páginas pre-generar
export async function getStaticPaths() {
  const posts = await fetchAllPosts();
  return {
    paths: posts.map(post => ({ params: { slug: post.slug } })),
    fallback: 'blocking'
  };
}

Esto ya permitía:

  • SSG (Static Site Generation): HTML generado en build time
  • SSR (Server-Side Rendering): HTML generado por petición
  • ISR (Incremental Static Regeneration): Regeneración estática bajo demanda
  • CSR (Client-Side Rendering): Renderizado tradicional en el cliente

App Router: El siguiente nivel (2023+)

El App Router con React Server Components revoluciona el concepto:

// app/blog/[slug]/page.js
// Este es un Server Component por defecto
async function BlogPost({ params }) {
  // Fetch directo en el servidor, sin API route
  const post = await db.posts.findOne({ slug: params.slug });
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Content html={post.content} />
      
      {/* Este componente interactivo carga JS */}
      <LikeButton postId={post.id} />
      
      {/* Este componente es estático, cero JS */}
      <ShareLinks url={post.url} />
    </article>
  );
}

// app/blog/[slug]/LikeButton.jsx
'use client'; // Directiva explícita para Client Component

import { useState } from 'react';

export default function LikeButton({ postId }) {
  const [likes, setLikes] = useState(0);
  const [isLiked, setIsLiked] = useState(false);
  
  async function handleLike() {
    setIsLiked(!isLiked);
    await fetch('/api/like', {
      method: 'POST',
      body: JSON.stringify({ postId })
    });
    setLikes(prev => isLiked ? prev - 1 : prev + 1);
  }
  
  return (
    <button onClick={handleLike} className={isLiked ? 'liked' : ''}>
      ❤️ {likes}
    </button>
  );
}

Lo revolucionario aquí:

  1. Server Components por defecto: Ningún JavaScript se envía al cliente a menos que lo marques explícitamente con 'use client'
  2. Composición granular: Puedes mezclar Server y Client Components en el mismo árbol
  3. Data fetching colocalizado: No necesitas API routes separadas para datos internos
  4. Streaming automático: El contenido se envía al cliente progresivamente con Suspense

Patrones híbridos en acción

1. El patrón de «Shell + Contenido»

Ideal para aplicaciones con navegación persistente pero contenido dinámico:

// app/layout.js - Server Component
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {/* Navegación estática, zero JS */}
        <Navigation />
        
        {/* Contenido que puede ser Server o Client */}
        {children}
        
        {/* Footer estático */}
        <Footer />
      </body>
    </html>
  );
}

// app/dashboard/layout.js - Nested layout
export default function DashboardLayout({ children }) {
  return (
    <div className="dashboard">
      {/* Sidebar interactivo */}
      <Sidebar />
      
      {/* El contenido principal puede ser mayormente estático */}
      <main>{children}</main>
    </div>
  );
}

La navegación entre páginas del dashboard puede ser:

  • MPA: Primera carga con HTML completo del servidor
  • SPA: Navegaciones subsecuentes con transiciones suaves
  • Streaming: Contenido pesado se carga progresivamente

2. Progressive Enhancement con Forms

Los formularios son un caso perfecto para híbridos:

// app/contact/page.js
import { submitContactForm } from './actions';

export default function ContactPage() {
  return (
    <form action={submitContactForm}>
      <input name="email" type="email" required />
      <textarea name="message" required />
      
      {/* Funciona sin JavaScript (POST tradicional) */}
      <button type="submit">Enviar</button>
      
      {/* Enhancement opcional con JS */}
      <FormValidator />
    </form>
  );
}

// app/contact/actions.js
'use server';

export async function submitContactForm(formData) {
  const email = formData.get('email');
  const message = formData.get('message');
  
  // Validación y procesamiento en el servidor
  await db.contacts.create({ email, message });
  
  // Redirección o respuesta
  return { success: true };
}

Sin JavaScript: El formulario funciona como POST tradicional. Con JavaScript: Se puede agregar validación en tiempo real, feedback visual, etc.

3. Islas de Interactividad

El patrón popularizado por Astro, pero aplicable en cualquier framework:

// Componente de E-commerce
export default async function ProductPage({ params }) {
  const product = await fetchProduct(params.id);
  
  return (
    <>
      {/* Contenido estático - cero JS */}
      <ProductGallery images={product.images} />
      <ProductDescription content={product.description} />
      <ProductSpecs specs={product.specs} />
      
      {/* Isla interactiva #1 - Selector de variantes */}
      <VariantSelector 
        variants={product.variants}
        client:visible 
      />
      
      {/* Isla interactiva #2 - Carrito */}
      <AddToCart 
        productId={product.id}
        client:idle 
      />
      
      {/* Isla interactiva #3 - Reviews con paginación */}
      <ReviewsList 
        productId={product.id}
        client:visible 
      />
    </>
  );
}

Las directivas como client:visible o client:idle controlan cuándo se hidrata cada componente:

  • client:load: Inmediatamente
  • client:idle: Cuando el navegador está inactivo
  • client:visible: Cuando el componente entra en el viewport
  • client:media: Basado en media queries

Remix: Otro enfoque híbrido

Remix toma un camino diferente pero igualmente interesante:

// routes/products.$id.jsx
import { json } from "@remix-run/node";
import { useLoaderData, useFetcher } from "@remix-run/react";

// Server-side data loading
export async function loader({ params }) {
  const product = await db.product.findUnique({
    where: { id: params.id }
  });
  return json(product);
}

// Server-side mutations
export async function action({ request }) {
  const formData = await request.formData();
  await addToCart(formData.get('productId'));
  return json({ success: true });
}

export default function Product() {
  const product = useLoaderData();
  const fetcher = useFetcher();
  
  return (
    <div>
      <h1>{product.name}</h1>
      
      {/* Funciona sin JS como form tradicional */}
      {/* Con JS, se convierte en fetch optimista */}
      <fetcher.Form method="post">
        <input type="hidden" name="productId" value={product.id} />
        <button type="submit">Add to Cart</button>
      </fetcher.Form>
    </div>
  );
}

La filosofía de Remix:

  • Usa web standards (forms, HTTP)
  • Funciona sin JavaScript por defecto
  • Progressive enhancement con JavaScript
  • Optimistic UI y prefetching automático

Estrategias de caché híbridas

Las arquitecturas híbridas brillan en el manejo de caché:

// Next.js App Router
export default async function ProductList() {
  // Cache estático para datos estables
  const categories = await fetch('https://api.com/categories', {
    cache: 'force-cache'
  });
  
  // Revalidación cada 60 segundos para datos semi-dinámicos
  const featured = await fetch('https://api.com/featured', {
    next: { revalidate: 60 }
  });
  
  // Sin cache para datos en tiempo real
  const inventory = await fetch('https://api.com/inventory', {
    cache: 'no-store'
  });
  
  return (
    <div>
      <Categories data={categories} /> {/* Estático */}
      <FeaturedProducts data={featured} /> {/* ISR */}
      <InventoryStatus data={inventory} /> {/* Dinámico */}
    </div>
  );
}

Tres niveles de freshness en una misma página, cada uno optimizado para su propósito.

View Transitions API: El puente entre MPA y SPA

La View Transitions API del navegador permite que las MPAs tengan transiciones suaves como SPAs:

// Código simple para transiciones entre páginas
document.addEventListener('click', (e) => {
  const link = e.target.closest('a');
  if (!link) return;
  
  e.preventDefault();
  
  // Transición suave entre páginas
  document.startViewTransition(async () => {
    await navigateToPage(link.href);
  });
});

/* Animación personalizada */
::view-transition-old(root) {
  animation: slide-out 0.3s ease-out;
}

::view-transition-new(root) {
  animation: slide-in 0.3s ease-in;
}

Astro y otros frameworks ya están integrando esto nativamente, eliminando una de las últimas ventajas exclusivas de las SPAs.

Métricas y rendimiento

Las arquitecturas híbridas permiten optimizar métricas específicas por sección:

Para páginas de marketing (landing, home):

  • Prioridad: LCP, FCP – primera impresión
  • Estrategia: SSG o SSR con mínimo JavaScript
  • Resultado: Sub-segundo en LCP

Para dashboards internos:

  • Prioridad: INP, TTI – interactividad fluida
  • Estrategia: SPA con pre-carga de datos
  • Resultado: Transiciones instantáneas

Para e-commerce:

  • Prioridad: Balance – conversión + UX
  • Estrategia: Híbrido con islas interactivas
  • Resultado: Rápido carga inicial + carrito fluido

Decisiones arquitectónicas prácticas

¿Cuándo hacer un componente Server Component?

✅ Sí, si:

  • Realiza fetching de datos
  • Contiene lógica sensible (API keys, secrets)
  • Renderiza contenido estático o semi-estático
  • No requiere interactividad (event handlers, hooks)

❌ No, si:

  • Necesita useState, useEffect, o cualquier hook
  • Maneja eventos del usuario (onClick, onChange)
  • Usa APIs del navegador (localStorage, window)
  • Requiere librerías client-only

¿Cuándo enviar JavaScript al cliente?

Solo cuando el valor de la interactividad supera el costo del JavaScript:

Vale la pena:

  • Formularios con validación en tiempo real
  • Carrito de compras con actualizaciones optimistas
  • Búsqueda con autocompletado
  • Dashboards interactivos
  • Drag and drop
  • Editores ricos

No vale la pena:

  • Animaciones simples (usa CSS)
  • Navegación básica (usa links nativos)
  • Tooltips (usa CSS o atributos HTML)
  • Acordeones simples (usa <details>)
  • Tabs básicos (usa CSS)

El futuro de las arquitecturas híbridas

Las tendencias emergentes indican más granularidad:

  1. Server Actions: Mutaciones tipadas del servidor sin API routes
  2. Partial Prerendering: Next.js 15+ mezcla estático y dinámico en la misma página
  3. React Server Components everywhere: Adopción en más frameworks
  4. Edge rendering: Renderizado distribuido más cerca del usuario
  5. Streaming por defecto: Contenido progresivo como estándar

Conclusión

Las arquitecturas híbridas no son un compromiso, son una evolución. Nos permiten:

  • Optimizar por sección: Cada parte de la app usa la estrategia correcta
  • Mejor DX: Escribir código más simple y mantener menos estado
  • Mejor UX: Carga rápida + interactividad donde importa
  • Mejor performance: Menos JavaScript = más velocidad
  • Progressive enhancement: Funcionalidad básica para todos, mejoras para los que pueden

La pregunta ya no es «¿SPA o MPA?» sino «¿qué nivel de JavaScript necesita cada pieza de mi aplicación?». Y los frameworks modernos nos dan las herramientas para responder esa pregunta con precisión quirúrgica.

El futuro del desarrollo web es híbrido, contextual y pragmático. Y ya está aquí.

Frameworks para explorar:

  • Next.js 14+ con App Router y React Server Components
  • Remix con su enfoque web-standard
  • SvelteKit con su excelente DX y performance
  • Astro para contenido con islas de interactividad
  • Nuxt 3 con Vue y arquitectura híbrida

Categorías

Desarrollo Web
← Volver al Blog