Construir un backend completo dentro de Next.js es más accesible de lo que parece. Gracias a los route handlers, puedes exponer endpoints propios, reutilizar servicios que ya tienes implementados y proteger información sensible aplicando un patrón conocido como back for frontend. Todo esto sin salir del mismo proyecto.
¿Qué son los route handlers y cómo se crean?
Next.js utiliza archivos especiales con la extensión route.ts para definir endpoints de API. A diferencia de los archivos page.tsx, que renderizan páginas, un route handler expone una ruta como si fuera un servicio backend tradicional [01:00].
Para comenzar, basta con crear una carpeta llamada api dentro de la estructura de rutas del proyecto y, dentro de ella, un archivo route.ts. La sintaxis es directa:
typescript
export async function GET() {
const message = "Hello World!";
return Response.json({ message });
}
- El nombre de la función corresponde al verbo HTTP que deseas implementar:
GET, POST, PATCH, entre otros.
- El objeto
Response viene integrado en Next.js y es estándar en cualquier aplicación de Node.js [02:15].
- Puedes consultar la documentación oficial de Next.js para ver todos los verbos disponibles.
¿Cómo reutilizar servicios existentes en la API?
Una de las grandes ventajas de tener una arquitectura de servicios ya definida es que puedes importar funciones existentes directamente en tu route handler. Por ejemplo, si ya cuentas con una función getProducts que consulta datos de Shopify, la integración es inmediata [03:05]:
typescript
import { getProducts } from "@/services/products";
export async function GET() {
const products = await getProducts();
return Response.json(products);
}
Con esto, cualquier otro frontend podría consumir ese endpoint sin necesidad de replicar la lógica de conexión con el servicio externo.
¿Qué es la arquitectura back for frontend y por qué importa?
El patrón back for frontend consiste en crear una capa intermedia —un proxy server— que ofusca las peticiones originales hacia servicios externos [03:40]. En lugar de que el cliente llame directamente a una API de terceros, consume un endpoint interno de Next.js que se encarga de la comunicación real.
Para implementarlo, desde tu componente o página realizas un fetch al endpoint interno:
typescript
const response = await fetch("/api/products");
const products = await response.json();
- Primero recibes el objeto
response.
- Luego extraes la data con
.json().
- Los productos se obtienen de forma limpia, sin exponer detalles de la petición original [04:45].
¿Cuándo conviene usar esta estrategia?
No siempre es necesario pasar por un endpoint interno. Aquí la distinción clave [05:30]:
- React server components: al ejecutarse exclusivamente en el servidor, puedes consumir tus servicios de manera directa. Ninguna petición se refleja en el navegador del usuario.
- Client components: si consumes un servicio externo desde el lado del cliente, estás exponiendo headers, credenciales y cualquier dato sensible que viaje en la petición. En este caso, la capa de back for frontend es altamente recomendable.
El beneficio adicional es que estás construyendo una infraestructura reutilizable. Si mañana creas otro proyecto con Next.js, puedes apuntar directamente a esos endpoints ya probados y funcionando.
¿Qué ventajas de seguridad ofrece este enfoque?
Cuando un servicio externo tiene alguna vulnerabilidad o requiere enviar información sensible en la petición, exponerlo al cliente representa un riesgo real. Al interponer tu propio servidor como intermediario [06:20]:
- Toda la lógica de servicios vive únicamente en el servidor.
- La información llega al cliente de manera limpia.
- No se exponen headers ni datos de autenticación al navegador.
Crear una API con Next.js y sus route handlers es un proceso sencillo que aporta flexibilidad, seguridad y escalabilidad. Si ya trabajas con server components, aprovecha la comunicación directa; si necesitas client components, protege tus servicios con un endpoint interno. ¿Has implementado alguna variante de back for frontend en tus proyectos? Comparte tu experiencia.
