Next.js 15 en la práctica: cómo monté un blog de nivel producción en un fin de semana

Introducción

Next.js 15 salió hace poco. Leí la documentación oficial varias veces y vi bastantes tutoriales en vídeo, pero seguía sintiendo que era teoría: Server Actions, App Router… los conceptos los tenía, pero no sabía cómo aplicarlos en un proyecto real. Un fin de semana decidí dejar los tutoriales y hacer algo de verdad: un blog full stack. Frontend, backend, base de datos y despliegue. Dos días después el blog estaba en Vercel con 96 puntos en Lighthouse.

En este artículo comparto todo el proceso. No es un tutorial de copiar y pegar, sino entender el porqué y los agujeros por los que caí. El stack es Next.js 15 + Server Actions + Prisma + PostgreSQL, con código de nivel producción.

¿Por qué Next.js 15?

Elegir el stack me costó bastante.
Cuando salió Next.js 15, en la comunidad había quien decía «otra actualización más, no doy abasto». Siendo honesto, yo también tenía cierta resistencia: la 14 aún no la dominaba del todo. Pero al mirar las novedades con calma, esta actualización sí mereció la pena.

Server Actions: adiós a la pesadez de API Routes

Antes, lo que más me fastidiaba del full stack era escribir API Routes. Crear un api/posts/route.ts, definir POST, parsear el body, devolver la respuesta… siempre el mismo ritual, hasta el cansancio.
Server Actions cambió las reglas. Solo añades 'use server' delante de la función y la llamas desde el componente. La primera vez pensé: «¿Esto es meter código de backend en el frontend?» Lo probé una vez y… vaya diferencia.
Por ejemplo, antes para crear un post hacía algo así:

// Método antiguo: hace falta una API Route
// app/api/posts/route.ts
export async function POST(request: Request) {
  const body = await request.json()
  // montón de lógica...
}
// En el frontend además hay que hacer fetch
const response = await fetch('/api/posts', {
  method: 'POST',
  body: JSON.stringify(data)
})

Ahora basta con esto:

// app/actions/post-actions.ts
'use server'
export async function createPost(formData: FormData) {
  const title = formData.get('title')
  const content = formData.get('content')
  // Acceso directo a la base de datos
  return await prisma.post.create({
    data: { title, content }
  })
}

En el componente es como llamar a una función local. Una analogía: antes ibas tú al restaurante (API Routes); ahora el pedido llega a casa (Server Actions).

Turbopack: desarrollo mucho más rápido

Next.js 15 pasó Turbopack de experimental a estable. Oficialmente: arranque del servidor local un 76,7 % más rápido y actualización de código un 96,3 % más rápida. Al principio pensé que eran cifras de marketing; al usarlo vi que no exageraban.

Mi proyecto tiene más de 30 componentes. Con Webpack tardaba 7-8 segundos en arrancar; con Turbopack queda por debajo de 2. Al cambiar código, el hot reload es casi instantáneo. La mejora en la experiencia de desarrollo es enorme.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

¿Por qué este stack encaja con un blog?

Elegí Next.js por tres razones:
Ventaja natural de SSR/SSG — Lo más importante en un blog es el SEO. El render en servidor y la generación estática de Next.js están hechos para eso. El crawler de Google recibe HTML completo; mucho mejor que un React solo en cliente.
Tipado seguro con Prisma — Antes usé Mongoose con MongoDB y los tipos los llevaba a mano; un descuido y aparecían bugs. Prisma genera tipos TypeScript desde el schema; al escribir tienes autocompletado y casi no fallas.
Server Actions simplifican el desarrollo — Sin API Routes, al menos un 30 % menos de código. Con el enfoque clásico habría varios route.ts más.

Elección del stack y diseño de arquitectura

Con el porqué claro, toca el cómo.

Mi stack completo

• Frontend: Next.js 15 + TypeScript + Tailwind CSS
• Backend: Next.js Server Actions + NextAuth.js
• Base de datos: PostgreSQL + Prisma ORM
• Despliegue: Vercel
  ¿Por qué no MongoDB? Al principio también lo pensé; MongoDB es flexible. Pero Prisma encaja mejor con PostgreSQL, y para posts, usuarios y comentarios —relaciones claras— una base relacional suele ir mejor.

Estructura de directorios

my-blog/
├── app/
│   ├── (auth)/          # Páginas de autenticación
│   ├── blog/            # Páginas del blog
│   │   └── [slug]/      # Ruta dinámica
│   ├── dashboard/       # Panel de usuario
│   ├── actions/         # Server Actions centralizadas
│   └── api/auth/        # Configuración de NextAuth
├── components/          # Componentes reutilizables
├── lib/
│   ├── prisma.ts        # Singleton de Prisma (¡importante!)
│   └── utils.ts         # Utilidades
├── prisma/
│   └── schema.prisma    # Schema de la base de datos
└── public/              # Recursos estáticos

La estructura la fui ajustando varias veces. Al principio tenía Server Actions repartidas en las páginas; luego creé la carpeta actions y todo quedó más ordenado.

Diseño del schema de base de datos

Aquí me metí en un buen lío. La primera versión era demasiado compleja: etiquetas, categorías, estadísticas de lectura… a mitad de camino vi que no necesitaba tantas tablas y perdí medio día simplificando.
El schema final quedó así:

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String?
  image     String?
  posts     Post[]
  createdAt DateTime @default(now())
}
model Post {
  id          String   @id @default(cuid())
  title       String
  slug        String   @unique
  content     String   @db.Text
  published   Boolean  @default(false)
  authorId    String
  author      User     @relation(fields: [authorId], references: [id])
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
  @@index([slug])
  @@index([authorId])
}

Fíjate en los dos @@index: clave para el rendimiento. La lista del blog consulta mucho por slug; el perfil del usuario filtra por authorId. Con índices, las consultas van varias veces más rápido.

Implementación de las funciones principales

Arquitectura lista; ahora lo mejor: escribir código.

3.1 Configuración del entorno e inicialización

Crear un proyecto Next.js 15 es muy sencillo:

npx create-next-app@latest my-blog
cd my-blog
npm install prisma @prisma/client zod next-auth

Tras instalar Prisma, inicializa:

npx prisma init

Genera prisma/schema.prisma y .env. En .env configura PostgreSQL:

DATABASE_URL="postgresql://username:password@localhost:5432/myblog?schema=public"

En local uso Docker para PostgreSQL, una línea:

docker run --name blog-postgres -e POSTGRES_PASSWORD=mypassword -p 5432:5432 -d postgres

3.2 Integración de Prisma

Con el schema listo, ejecuta la migración:

npx prisma migrate dev --name init

Cuidado con un detalle: el singleton de Prisma Client. La primera vez que desplegué en Vercel no lo configuré; a las pocas horas apareció Too many connections y pensé que era un DDoS.
En desarrollo, Next.js recarga en caliente y crea una instancia nueva en cada recarga; el pool se agota. La solución:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

// lib/prisma.ts
import { PrismaClient } from '@prisma/client'
const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClient | undefined
}
export const prisma = globalForPrisma.prisma ?? new PrismaClient()
if (process.env.NODE_ENV !== 'production') {
  globalForPrisma.prisma = prisma
}

Parece enrevesado, pero garantiza una sola instancia en desarrollo sin tocar producción. Es la práctica recomendada por Prisma.

3.3 Server Actions en la práctica

Crear posts es el núcleo; así quedan las Server Actions:

// app/actions/post-actions.ts
'use server'
import { prisma } from '@/lib/prisma'
import { revalidatePath } from 'next/cache'
import { z } from 'zod'
// Validación con Zod para máximo tipado seguro
const PostSchema = z.object({
  title: z.string().min(1, '标题不能为空').max(100),
  content: z.string().min(10, '内容至少10个字'),
  slug: z.string().regex(/^[a-z0-9-]+$/, 'slug只能包含小写字母、数字和横杠')
})
export async function createPost(formData: FormData) {
  // Validar datos
  const validatedFields = PostSchema.safeParse({
    title: formData.get('title'),
    content: formData.get('content'),
    slug: formData.get('slug')
  })
  if (!validatedFields.success) {
    return { error: '数据验证失败' }
  }
  try {
    const post = await prisma.post.create({
      data: {
        ...validatedFields.data,
        authorId: 'user-id-here' // En producción, desde la sesión
      }
    })
    // Revalidar caché para que el nuevo post aparezca al instante
    revalidatePath('/blog')
    return { success: true, post }
  } catch (error) {
    return { error: '创建文章失败' }
  }
}

En el componente:

// app/dashboard/new-post/page.tsx
import { createPost } from '@/app/actions/post-actions'
export default function NewPost() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="标题" />
      <textarea name="content" placeholder="内容" />
      <input name="slug" placeholder="URL slug" />
      <button type="submit">发布</button>
    </form>
  )
}

¿Lo ves? Sin useState, sin fetch, sin onSubmit. El formulario llama directamente a la Server Action; Next.js se encarga de serialización, red y errores.
Al principio no distinguía Server Actions de API Routes; luego lo entendí: pedido a domicilio frente a ir al restaurante. En la mayoría de casos, Server Actions bastan.

3.4 Autenticación de usuarios

Para auth usé NextAuth.js; la configuración es sencilla:

// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import GitHubProvider from 'next-auth/providers/github'
import { PrismaAdapter } from '@auth/prisma-adapter'
import { prisma } from '@/lib/prisma'
export const authOptions = {
  adapter: PrismaAdapter(prisma),
  providers: [
    GitHubProvider({
      clientId: process.env.GITHUB_ID!,
      clientSecret: process.env.GITHUB_SECRET!
    })
  ]
}
const handler = NextAuth(authOptions)
export { handler as GET, handler as POST }

Para GitHub OAuth creas una app en GitHub Developer Settings, copias Client ID y Secret a .env. Unos 10 minutos; mucho menos trabajo que un JWT casero.

3.5 Estrategia SSR/SSG

Aquí está la clave del rendimiento. Al principio usé solo SSR y cada visita a la lista del blog pegaba a la base de datos sin necesidad. Pasé a una estrategia mixta:
Lista del blog — SSG + ISR:

// app/blog/page.tsx
import { prisma } from '@/lib/prisma'
// Regenerar cada hora
export const revalidate = 3600
export default async function BlogList() {
  const posts = await prisma.post.findMany({
    where: { published: true },
    orderBy: { createdAt: 'desc' }
  })
  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.content.slice(0, 150)}...</p>
        </article>
      ))}
    </div>
  )
}

La página se genera en el build y se regenera cada hora. El usuario recibe HTML estático; carga rapidísima.
Detalle del post — SSR dinámico:

// app/blog/[slug]/page.tsx
export default async function Post({ params }: { params: { slug: string } }) {
  const post = await prisma.post.findUnique({
    where: { slug: params.slug }
  })
  if (!post) notFound()
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}

Cada visita consulta la base para el contenido más reciente; ideal para posts que cambian a menudo.
Comparativa de rendimiento:

La diferencia es clara. Por eso Next.js encaja tan bien con blogs: buen SEO y buen rendimiento.

Despliegue y optimización

Código listo; lo más emocionante: publicar.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Despliegue en Vercel

Subí el código a GitHub e importé el repo en Vercel. Detectó Next.js y configuró casi todo. Solo toca las variables de entorno:

DATABASE_URL="tu conexión de base de datos en producción"
GITHUB_ID="OAuth Client ID"
GITHUB_SECRET="OAuth Secret"
NEXTAUTH_URL="https://your-domain.vercel.app"
NEXTAUTH_SECRET="cadena aleatoria"

En producción uso el PostgreSQL gratuito de Supabase: 500 MB al mes, de sobra para un blog personal.
Tras Deploy, en unos 2 minutos el sitio estaba en línea. La primera vez que vi mi dominio funcionando me quedé mirando la pantalla unos segundos y no pude evitar hacer una captura.

Optimización en producción

Desplegar no es el final; quedan varios ajustes:
Pool de conexiones de Prisma:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  // Obligatorio en Vercel serverless
  directUrl = env("DIRECT_URL")
}

En serverless cada invocación puede abrir una conexión nueva; directUrl permite reutilizar el pool.
Optimización de imágenes:

import Image from 'next/image'
<Image
  src="/avatar.jpg"
  alt="用户头像"
  width={100}
  height={100}
  // Next.js comprime y optimiza automáticamente
/>

El componente Image convierte a WebP y carga bajo demanda; la mejora es notable.
Puntuación final:

Con Lighthouse: 96 en escritorio, 92 en móvil, SEO 100. Ver ese resultado da mucha satisfacción: dos días, de cero a producción, con rendimiento real.

Extensiones y recursos de aprendizaje

El blog es un MVP; se pueden añadir muchas cosas:

• Editor Markdown: integrar react-md-editor
• Comentarios: Giscus (basado en GitHub Discussions)
• Búsqueda: Algolia o búsqueda de texto completo con Prisma
• Modo oscuro: con next-themes es sencillo
  Lo siguiente que haré es un editor Markdown; escribir posts será mucho más cómodo.
  Recursos recomendados:
• Documentación oficial de Next.js — siempre la referencia
• Documentación de Prisma — con leer Getting Started basta
• El código completo de este proyecto — puedes clonarlo y ejecutarlo
  Créeme: hacerlo una vez vale más que leer diez documentos. La teoría ayuda, pero solo la práctica te lo deja interiorizado.

Resumen

Repasando lo aprendido en este fin de semana:

1. La potencia de Server Actions: pueden sustituir la mayoría de API Routes; la eficiencia sube muchísimo
2. Tipado seguro con Prisma: con TypeScript completo, codificar da tranquilidad
3. Flexibilidad SSG/SSR: elegir la estrategia según el caso; rendimiento y SEO a la vez
4. La simplicidad de Vercel: del código a producción en menos de 5 minutos
   Siendo honesto, lo que más me llevé no fue la técnica en sí, sino la confianza: el full stack no es tan imposible si te pones manos a la obra.
   Si quieres montar tu propio blog, no lo pienses más: empieza ya. Es normal tropezar; yo también consultaba documentación mientras escribía y caí en mil agujeros. Pero cuando ves tu trabajo en línea, todo compensa.
   Espero que este artículo te ahorre algunos desvíos. Si tienes dudas, comenta; intentaré responder.
   ¡Tengo ganas de ver lo que construyas!