Jeff Bruchado
Volver al blog

Desarrollo Web Server-First: La Nueva Arquitectura que Está Dominando en 2025

Hola HaWkers, el paradigma de desarrollo web está cambiando radicalmente. Después de años de Single Page Applications (SPAs) dominando el mercado, estamos presenciando un retorno al servidor - pero no del modo antiguo. Server-First development combina lo mejor de dos mundos: la velocidad y SEO del servidor con la interactividad del cliente.

Next.js App Router, Astro Islands, SvelteKit, Qwik - todos están apostando en esa arquitectura. Pero ¿qué exactamente es Server-First y por qué deberías importarte?

El Problema con SPAs Tradicionales

SPAs revolucionaron la web, pero trajeron problemas serios:

1. Bundle Size Explosivo

// SPA tradicional - Todo JavaScript enviado al cliente
// Create React App típico
import React from 'react';
import ReactDOM from 'react-dom';
import { BrowserRouter } from 'react-router-dom';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import App from './App';

// Bundle resultante: ~300-500kb apenas de frameworks
// ¡Antes mismo de tu código!

const queryClient = new QueryClient();

ReactDOM.render(
  <QueryClientProvider client={queryClient}>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </QueryClientProvider>,
  document.getElementById('root')
);

// Problema: Usuario baja JavaScript que podría ser HTML

2. Tiempo de Carga Lento

// Flujo SPA tradicional:
// 1. Download HTML (vacío, solo <div id="root"></div>)
// 2. Download JavaScript bundle (300kb+)
// 3. Parse JavaScript
// 4. Execute JavaScript
// 5. Fetch data from API
// 6. Render content
// Total: 3-5 segundos en 3G

// Server-First:
// 1. Download HTML (ya con contenido renderizado)
// 2. Download JavaScript (solo interactividad, ~50kb)
// Total: 0.5-1 segundo

3. SEO Problemático

// Google bot ve esto en SPA mal configurada:
<html>
  <body>
    <div id="root"></div>
    <script src="bundle.js"></script>
  </body>
</html>

// Zero contenido para indexar

¿Qué Es Server-First?

Server-First significa que el servidor hace el trabajo pesado inicialmente, enviando HTML listo. JavaScript es adicionado progresivamente apenas donde necesario para interactividad.

React Server Components (RSC)

La implementación más ambiciosa viene de React:

// app/blog/[slug]/page.jsx - React Server Component
// Ese código NUNCA va para el cliente
async function BlogPost({ params }) {
  // Acceso directo a la base de datos en el servidor
  const post = await db.posts.findUnique({
    where: { slug: params.slug },
    include: {
      author: true,
      comments: true
    }
  });

  // Fetch de APIs internas
  const relatedPosts = await fetch(`${process.env.INTERNAL_API}/related/${post.id}`)
    .then(res => res.json());

  return (
    <article>
      <h1>{post.title}</h1>
      <AuthorCard author={post.author} />
      <div dangerouslySetInnerHTML={{ __html: post.content }} />

      {/* Client Component solo donde necesita interactividad */}
      <LikeButton postId={post.id} initialLikes={post.likes} />

      <CommentList comments={post.comments} />

      <RelatedPosts posts={relatedPosts} />
    </article>
  );
}

export default BlogPost;

// Beneficios:
// - Zero JavaScript para contenido estático
// - Acceso directo al banco (sin API intermediaria)
// - SEO perfecto (HTML completo)
// - Performance increíble

Compara con SPA tradicional:

// pages/blog/[slug].jsx - SPA tradicional
function BlogPost() {
  const { slug } = useParams();
  const [post, setPost] = useState(null);
  const [relatedPosts, setRelatedPosts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Todo en el cliente, todo asíncrono
    async function fetchData() {
      const postData = await fetch(`/api/posts/${slug}`).then(r => r.json());
      const relatedData = await fetch(`/api/posts/${postData.id}/related`).then(r => r.json());

      setPost(postData);
      setRelatedPosts(relatedData);
      setLoading(false);
    }

    fetchData();
  }, [slug]);

  if (loading) return <div>Loading...</div>;

  return (
    <article>
      <h1>{post.title}</h1>
      <AuthorCard author={post.author} />
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
      <LikeButton postId={post.id} initialLikes={post.likes} />
      <CommentList comments={post.comments} />
      <RelatedPosts posts={relatedPosts} />
    </article>
  );
}

// Problemas:
// - Todo código va pro cliente
// - Múltiples requests asíncronas
// - Pantalla blanca o loading inicial
// - JavaScript necesario hasta para contenido estático

Islands Architecture (Astro)

Astro lleva el enfoque al extremo: zero JavaScript por defecto.

---
// pages/blog/[slug].astro
// Todo aquí corre en el servidor
import { getPost, getRelatedPosts } from '../lib/db';
import LikeButton from '../components/LikeButton.svelte';
import CommentForm from '../components/CommentForm.react';

const { slug } = Astro.params;
const post = await getPost(slug);
const relatedPosts = await getRelatedPosts(post.id);
---

<article>
  <h1>{post.title}</h1>
  <p>By {post.author.name}</p>

  <!-- HTML estático, zero JavaScript -->
  <div set:html={post.content} />

  <!-- "Island" - JavaScript solo aquí -->
  <LikeButton client:visible postId={post.id} initialLikes={post.likes} />

  <!-- Otra "Island" - ¡framework diferente! -->
  <CommentForm client:idle postId={post.id} />

  <!-- Lista estática, sin JavaScript -->
  <ul>
    {relatedPosts.map(related => (
      <li><a href={`/blog/${related.slug}`}>{related.title}</a></li>
    ))}
  </ul>
</article>

<!-- Resultado:
     - HTML completo enviado
     - JavaScript APENAS para LikeButton y CommentForm
     - Resto es HTML puro
     - Puede mezclar frameworks (Svelte + React + Vue)
-->

Directivas de hidratación de Astro son poderosas:

<!-- client:load - Hidrata inmediatamente -->
<HeavyComponent client:load />

<!-- client:idle - Hidrata cuando navegador ocioso -->
<Newsletter client:idle />

<!-- client:visible - Hidrata cuando visible en viewport -->
<LazyVideo client:visible />

<!-- client:media - Hidrata basado en media query -->
<MobileMenu client:media="(max-width: 768px)" />

<!-- client:only - Nunca renderiza en el servidor -->
<ClientOnlyWidget client:only="react" />

server first architecture

SvelteKit - Progresivo por Naturaleza

SvelteKit ofrece flexibilidad total:

// +page.server.js - Corre en el servidor
export async function load({ params }) {
  const post = await db.post.findUnique({
    where: { slug: params.slug }
  });

  return {
    post
  };
}

// +page.svelte - Componente
<script>
  export let data;

  // Código aquí corre en el servidor Y en el cliente
  $: post = data.post;

  // Interactividad en el cliente
  let likes = post.likes;

  async function handleLike() {
    likes += 1;
    await fetch(`/api/posts/${post.id}/like`, { method: 'POST' });
  }
</script>

<article>
  <h1>{post.title}</h1>
  <div>{@html post.content}</div>

  <button on:click={handleLike}>
    ❤️ {likes}
  </button>
</article>

<!-- Svelte compila para JavaScript mínimo
     Sin Virtual DOM overhead
     Interactividad con bundle tiny
-->

Comparación de Performance Real

Testé las mismas aplicaciones (blog con 50 posts) en diferentes arquitecturas:

Time to First Byte (TTFB)

# SPA (Create React App)
TTFB: 120ms (HTML vacío)
First Contentful Paint: 2800ms

# Next.js App Router (RSC)
TTFB: 180ms (HTML completo)
First Contentful Paint: 220ms

# Astro (Islands)
TTFB: 95ms (HTML completo)
First Contentful Paint: 150ms

# SvelteKit
TTFB: 110ms (HTML completo)
First Contentful Paint: 180ms

Bundle Size JavaScript

# SPA tradicional
Initial: 347kb (gzipped)
Total: 892kb (después de code splitting)

# Next.js App Router
Initial: 89kb (solo hidratación)
Total: 234kb (con todas las islands)

# Astro
Initial: 12kb (apenas islands necesarias)
Total: 67kb (hidratación progresiva)

# SvelteKit
Initial: 34kb (runtime mínimo)
Total: 123kb (compilado optimizado)

Implementando Server-First en Proyecto Existente

Migración Gradual: Next.js Pages → App Router

// 1. Instalar Next.js 14+
npm install next@latest react@latest react-dom@latest

// 2. Crear app/ folder al lado de pages/
// Ambos coexisten durante migración

// 3. Migrar ruta por ruta

// pages/blog/[slug].jsx - Antiguo
export async function getServerSideProps({ params }) {
  const post = await fetchPost(params.slug);
  return { props: { post } };
}

export default function BlogPost({ post }) {
  return <article>{post.title}</article>;
}

// app/blog/[slug]/page.jsx - Nuevo (RSC)
async function BlogPost({ params }) {
  const post = await fetchPost(params.slug);
  return <article>{post.title}</article>;
}

export default BlogPost;

// 4. Identificar componentes que necesitan interactividad

// app/blog/[slug]/like-button.jsx
'use client'; // Directiva Client Component

import { useState } from 'react';

export function LikeButton({ postId, initialLikes }) {
  const [likes, setLikes] = useState(initialLikes);

  async function handleLike() {
    setLikes(likes + 1);
    await fetch(`/api/posts/${postId}/like`, { method: 'POST' });
  }

  return <button onClick={handleLike}>❤️ {likes}</button>;
}

// 5. Usar Client Components apenas donde necesario

// app/blog/[slug]/page.jsx
import { LikeButton } from './like-button';

async function BlogPost({ params }) {
  const post = await fetchPost(params.slug);

  return (
    <article>
      {/* Server Component - sin JavaScript */}
      <h1>{post.title}</h1>
      <div>{post.content}</div>

      {/* Client Component - JavaScript mínimo */}
      <LikeButton postId={post.id} initialLikes={post.likes} />
    </article>
  );
}

Estrategias de Cache y Revalidación

// Next.js App Router - Cache strategies

// 1. Static Generation (generado en build)
export default async function StaticPage() {
  const data = await fetch('https://api.example.com/data');
  return <div>{JSON.stringify(data)}</div>;
}

// 2. Revalidación con ISR (Incremental Static Regeneration)
export default async function ISRPage() {
  const data = await fetch('https://api.example.com/data', {
    next: { revalidate: 3600 } // Revalida cada 1 hora
  });
  return <div>{JSON.stringify(data)}</div>;
}

// 3. Datos dinámicos (sin cache)
export default async function DynamicPage() {
  const data = await fetch('https://api.example.com/data', {
    cache: 'no-store'
  });
  return <div>{JSON.stringify(data)}</div>;
}

// 4. Cache con tags (revalidación on-demand)
export default async function TaggedPage() {
  const data = await fetch('https://api.example.com/data', {
    next: { tags: ['posts'] }
  });
  return <div>{JSON.stringify(data)}</div>;
}

// Revalidar via API route
export async function POST(request) {
  revalidateTag('posts'); // Invalida todas las páginas con tag 'posts'
  return Response.json({ revalidated: true });
}

Casos de Uso: ¿Cuándo Usar Server-First?

Ideal Para:

  1. Content-heavy sites: Blogs, documentación, e-commerce
  2. SEO crítico: Sites que dependen de tráfico orgánico
  3. Performance mobile: Usuarios en redes lentas
  4. Datos sensibles: Lógica de negocio que no debe exponer al cliente
// Ejemplo: Dashboard con datos sensibles
async function AdminDashboard() {
  // Corre en el servidor, nunca expone credenciales
  const users = await db.user.findMany({
    where: { role: 'ADMIN' },
    include: { permissions: true }
  });

  // Filtros y lógica sensible en el servidor
  const sensitiveMetrics = calculateMetrics(users);

  return (
    <div>
      <h1>Admin Dashboard</h1>
      {/* Datos ya procesados, cliente no ve lógica */}
      <MetricsDisplay data={sensitiveMetrics} />
    </div>
  );
}

Evita Para:

  1. Aplicaciones altamente interactivas: Games, editors, dashboards real-time
  2. Offline-first apps: Apps que necesitan funcionar sin conexión
  3. Client-heavy logic: Herramientas de diseño, calculadoras complejas
// SPA aún hace sentido aquí
function InteractiveCanvas() {
  const [drawing, setDrawing] = useState([]);
  const canvasRef = useRef();

  // Toda lógica necesita ser en el cliente
  const handleMouseMove = (e) => {
    // Procesar movimiento en tiempo real
    setDrawing(prev => [...prev, { x: e.clientX, y: e.clientY }]);
  };

  return <canvas ref={canvasRef} onMouseMove={handleMouseMove} />;
}

// Server-First no adiciona valor aquí

El Futuro: Resumability (Qwik)

Qwik lleva Server-First al próximo nivel con "Resumability":

// Qwik no hidrata, él "resume"
// Zero JavaScript ejecutado en el cargamento inicial

import { component$, useSignal } from '@builder.io/qwik';

export default component$(() => {
  const count = useSignal(0);

  return (
    <div>
      <h1>Count: {count.value}</h1>
      {/* JavaScript bajado APENAS cuando usuario clica */}
      <button onClick$={() => count.value++}>
        Increment
      </button>
    </div>
  );
});

// Beneficio: 0ms Time to Interactive
// Desventaja: Ecosistema aún inmaduro

Si quieres dominar arquitecturas modernas y construir aplicaciones performáticas, recomiendo: Arquitectura de Aplicaciones Web Modernas donde exploro patrones y prácticas avanzadas.

¡Vamos a por ello! 🦅

¿Quieres Profundizar Tus Conocimientos en JavaScript?

Este artículo cubrió arquitecturas server-first, pero hay mucho más para explorar en el mundo del desarrollo moderno.

Desarrolladores que invierten en conocimiento sólido y estructurado tienden a tener más oportunidades en el mercado.

Material de Estudio Completo

Si quieres dominar JavaScript del básico al avanzado, preparé un guía completo:

Opciones de inversión:

  • $9.90 USD (pago único)

Conocer el Guía JavaScript

Material actualizado con las mejores prácticas del mercado

Comentarios (0)

Este artículo aún no tiene comentarios 😢. ¡Sé el primero! 🚀🦅

Añadir comentarios