Contenido del curso

Características Adicionales y Herramientas

Drizzle ORM en lugar de fetch en Next.js

Resumen

Consumir datos desde el servidor en Next.js no se limita a usar fetch contra una API. Con un ORM como Drizzle puedes conectar tu Server Component directamente con la base de datos, eliminar capas intermedias y mantener un código más limpio y tipado. Esta práctica resulta clave si trabajas con React Server Components y buscas eficiencia real en producción.

Qué es un ORM y por qué usarlo en Next.js

Un ORM (Object Relational Mapper) es un manejador de datos relacionales que simplifica la comunicación con tu base de datos. En lugar de escribir queries crudos, difíciles de leer y mantener, declaras operaciones en código que el ORM traduce por ti.

En el proyecto trabajamos con Drizzle, un ORM moderno y muy amigable con TypeScript. Sigue usando Postgres por debajo para conectarse, pero delega en Drizzle todas las operaciones contra la base de datos [02:10].

¿Qué es Drizzle? Es un ORM para TypeScript que se conecta a bases de datos como Postgres y te permite escribir queries tipados, evitando SQL crudo y mejorando la mantenibilidad.

Por qué evitar el fetch contra tu propia API en el servidor

Cuando un Server Component hace fetch a una API del mismo proyecto, necesitas usar URLs absolutas. Eso se vuelve incómodo en desarrollo y problemático en producción, porque tienes que resolver dominios y rutas que ya viven dentro de tu propio servidor.

La pregunta natural es: si la API solo está envolviendo una operación de base de datos, ¿para qué pasar por ella? Puedes ir directo al origen de los datos.

  • En App > Bookmarks > page teníamos un fetch contra /api/bookmarks [01:20].
  • Esa API a su vez ejecutaba un query con el ORM contra la tabla bookmarks.
  • Resultado: una capa intermedia innecesaria cuando el componente ya corre en el servidor.

¿Por qué se necesitan URLs absolutas en Server Components? Porque el código se ejecuta en el servidor, no en el navegador, y no hay un origin relativo al usuario. Por eso conviene saltarse el fetch y consultar la base de datos directamente.

Cómo reemplazar fetch por una consulta directa con Drizzle

El manejador de la ruta en App > Bookmarks API respondía a un GET ejecutando un query con Drizzle a la tabla bookmarks, trayendo los 10 primeros registros e incluyendo la relación con el autor [02:00]. Ese mismo query lo movemos al Server Component.

Pasos para migrar la lectura al Server Component

  1. Eliminar el fetch a la URL absoluta dentro de la página.
  2. Importar el ORM desde el archivo de configuración de la base de datos (db).
  3. Ejecutar el query como una operación asíncrona dentro del componente.
  4. Renombrar la variable a bookmarks, ya que el ORM devuelve el tipo correcto.
  5. Quitar el type manual del esquema, porque Drizzle infiere el tipo automáticamente.

Al recargar la página, la aplicación de Experience Tracker sigue mostrando los bookmarks, pero ahora todo viaja directo desde el servidor sin pasar por una API intermedia [03:30]. Si revisas el HTML, los datos ya vienen renderizados en el servidor.

Qué optimiza Next.js detrás de escena

Next.js se encarga de que el código del servidor no se filtre al cliente. Tu navegador recibe únicamente el resultado renderizado, no la lógica de conexión a base de datos ni las credenciales. Esa es la magia de los React Server Components: escribes código de servidor dentro de tus componentes y el framework hace la separación.

Cuándo conviene usar fetch, SQL crudo o un ORM

Ya viste tres formas de traer datos desde el servidor en Next.js, y cada una tiene su lugar.

  • Fetch contra una API: útil cuando consumes servicios externos o APIs públicas.
  • Consultas SQL directas: funcionan, pero son difíciles de mantener y no aprovechan el tipado.
  • ORM como Drizzle: la opción más común en entornos profesionales por su eficiencia y soporte TypeScript.

En la experiencia real, lo que más vas a encontrar en proyectos profesionales son flujos basados en ORM. Te ayudan a resolver queries complejos, manejar relaciones y mantener un código tipado de punta a punta.

¿Has migrado ya alguno de tus fetch internos a consultas directas con un ORM? Cuéntame en los comentarios qué stack estás usando y qué cambios notaste en rendimiento.