Si trabajas con Laravel y ya has construido interfaces con Livewire, seguramente te suena este “baile” diario: una parte en PHP, otra en Blade, y cuando necesitas interacción más específica… terminas tocando también JavaScript. No es que sea imposible, pero sí es un flujo que puede sentirse fragmentado, especialmente en componentes pequeños o medianos.

En la comunidad se está hablando mucho de Livewire 4 porque apunta justo a ese dolor: reducir el cambio constante entre archivos y hacer que el desarrollo sea más directo y rápido.

Inspirado en esta lectura (en inglés): Livewire 4 is Here: A New Era of Faster Laravel Development

El problema clásico: demasiadas piezas para un componente simple

Pensemos en un componente típico como un contador:

• Lógica del estado y acciones en PHP
• Vista en Blade
• Scripts puntuales si necesitas comportamiento extra

En proyectos grandes esto se organiza bien, pero en el día a día (y especialmente cuando estás iterando rápido) ese cambio de contexto puede volverse fricción: “¿dónde estaba esto?”, “¿en qué archivo lo dejé?”, “¿era aquí o en el JS?”.

Single‑File Components: todo en un solo archivo

Uno de los cambios más comentados de Livewire 4 es el enfoque de componentes de un solo archivo: poder definir lógica + plantilla + scripts en un único lugar.

Esto no es solo comodidad: suele traducirse en:

• Menos archivos por componente
• Menos tiempo navegando el proyecto
• Iteración más rápida (especialmente en componentes pequeños)
• Una experiencia más “cerrada”: abres un archivo y lo entiendes todo

Ejemplo conceptual: un contador “en una sola pieza”

La sintaxis exacta puede variar según tu configuración, pero el concepto general es: un único archivo que concentra lo que antes vivía separado.

Livewire Islands: interactividad “por partes” (solo donde la necesitas)

Otra idea potente en Livewire 4 es el enfoque de islas (islands): en vez de convertir una página completa en algo altamente interactivo, puedes marcar secciones específicas como “islas” de Livewire.

¿Para qué sirve esto?

• Páginas mayormente estáticas (rápidas, cacheables) con pequeñas zonas dinámicas
• Mejor control del alcance de la reactividad
• Menos “peso” mental y técnico: Livewire actúa exactamente donde lo requieres

Si te interesa esta parte, la documentación oficial lo explica aquí: Directive Island (Livewire 4.x)

En términos prácticos: “islas” es una forma de decir “no necesito que todo sea Livewire, solo esta sección”.

¿Y si mi proyecto ya usa Class Components? Puedes seguir igual

Un punto clave (y tranquilizador) es que no estás obligado a cambiar todo tu código a Single‑File Components.

Si tu base de código está construida con Class Components (el estilo tradicional de Livewire con clase PHP + vista Blade), puedes:

• Seguir trabajando así sin problema
• Adoptar Livewire 4 gradualmente
• Migrar componentes uno por uno cuando tenga sentido

Cambiar entre estilos: livewire:convert

Si quieres alternar o migrar componentes, Livewire ofrece un comando para convertirlos:

Esto te da un camino práctico para experimentar, comparar estilos y decidir por componente (no por proyecto completo).

¿Cuándo conviene usar cada enfoque?

Una forma simple de pensarlo:

• Single‑File Components

  • Ideal para componentes pequeños/medianos
  • Prototipado y desarrollo rápido
  • Cuando quieres tener “todo a la vista” en un solo lugar

• Class Components

  • Ideal si tu equipo ya tiene ese estándar
  • Componentes grandes con lógica más extensa
  • Cuando prefieres separación clara entre lógica y plantilla

• Islands

  • Ideal cuando la página es mayormente estática
  • Cuando quieres “inyectar” interactividad solo en zonas concretas
  • Útil para performance percibida y arquitectura más limpia

Por qué esto realmente puede hacerte más rápido

A veces “más rápido” suena a marketing, pero en desarrollo hay algo muy real: el costo del context switching. Abrir archivos, saltar entre carpetas, recordar qué va en cada sitio… todo eso suma.

Livewire 4 apunta a reducir esa fricción con dos palancas claras:

• Menos separación innecesaria (Single‑File Components cuando conviene)
• Menos reactividad global (Islands para dinamismo localizado)

Recomendaciones prácticas si lo aplicas en producción

1. No conviertas todo de golpe
   • Migra por módulos o pantallas.
2. Mide dónde te duele más
   • Componentes con mucha iteración suelen ser buen candidato a SFC.
3. Usa Islands estratégicamente
   • Formularios pequeños, buscadores, counters, widgets, etc.
4. Mantén consistencia por equipo
   • Define reglas: cuándo usar SFC, cuándo Class Components, cuándo Islands.

Cierre

Livewire siempre ha sido una forma excelente de construir interfaces dinámicas sin caer en complejidad innecesaria. Con Livewire 4, el mensaje parece claro: más flexibilidad, menos fricción, y un camino gradual para adoptar nuevas capacidades como Single‑File Components, Islands, o seguir con Class Components según lo que mejor encaje en tu proyecto.

Si estás empezando en el mundo full-stack con Laravel, es normal que te sientas un poco abrumado. De repente escuchas términos como “TALL stack”, “Inertia”, “reactividad”, “SPA”… y lo único que quieres es saber qué herramienta instalar para empezar a programar.

La buena noticia es que en Laravel tenemos dos “superpoderes” para crear aplicaciones modernas sin volvernos locos: Livewire e Inertia.js.

Ambos sirven para lo mismo (hacer que tu web se sienta rápida y fluida como una aplicación móvil), pero funcionan de forma muy distinta. Después de probar ambos, he llegado a la conclusión de que la mejor forma de elegir no es por “cuál es mejor”, sino por “qué estás construyendo”.

Aquí te cuento cómo lo veo yo, de tú a tú.

1. Paneles Internos y Herramientas de Gestión (Backoffice)

Mi elección: Livewire

Si te han pedido un panel para gestionar usuarios, un inventario o una herramienta interna para una empresa, Livewire es el rey.

¿Por qué? Porque en estos proyectos lo que importa es la velocidad de desarrollo. Con Livewire no tienes que salirte de Laravel. Escribes tu lógica en PHP, usas tus vistas de Blade de toda la vida y, casi por arte de magia, todo se vuelve interactivo.

Además, si usas Filament (una librería increíble basada en Livewire), puedes tener un panel de administración profesional funcionando en una tarde. Para un perfil full-stack que quiere resultados rápidos sin pelearse con configuraciones complejas de JavaScript, esta es la vía rápida.

2. E-commerce y Sitios con mucho SEO

Mi elección: Livewire

Si vas a montar una tienda online o un sitio donde necesitas que Google te encuentre fácilmente (SEO), Livewire tiene una ventaja natural: renderiza todo en el servidor.

Cuando Google visita tu página hecha con Livewire, ve el contenido HTML directamente, igual que en una web tradicional. Con Inertia, aunque se puede configurar el renderizado en el servidor (SSR), es un paso extra que a veces da dolores de cabeza si estás empezando. Con Livewire, el SEO viene “de serie”.

3. Aplicaciones con UI muy pesada o “tipo Dashboard” complejo

Mi elección: Inertia.js

Imagina que estás creando una herramienta de edición de fotos online, un gestor de tareas con mucho “drag and drop” (arrastrar y soltar) o una red social con mil notificaciones en tiempo real. Aquí es donde Inertia.js brilla.

Inertia te permite usar Vue o React dentro de Laravel. Estos frameworks de JavaScript están diseñados específicamente para manejar interfaces muy complejas y estados que cambian constantemente en el navegador.

Si tu aplicación va a tener muchísima lógica en el “cliente” (el navegador del usuario), usar Inertia te da acceso a miles de librerías de Vue o React que ya resuelven estos problemas.

4. Proyectos SaaS (Software como Servicio)

Mi elección: Depende de tu stack favorito

Aquí es donde la cosa se pone interesante. Un SaaS suele ser una mezcla de todo lo anterior.

• Si vienes del mundo Backend: Ve por Livewire. Te sentirás más cómodo controlando todo desde PHP y usando Alpine.js para los toques de JavaScript.
• Si vienes del mundo Frontend: Ve por Inertia. Poder usar Vue o React mientras aprovechas toda la potencia de Laravel en el backend es, sencillamente, una delicia.

Entonces, ¿por cuál empiezo si soy principiante?

Si estás dando tus primeros pasos como full-stack, mi consejo personal es este: Empieza por Livewire.

La curva de aprendizaje es mucho más suave. No tienes que aprender cómo funciona un compilador de JavaScript complejo, ni preocuparte por cómo pasar datos entre dos mundos distintos. Todo se queda “en casa”, en Laravel.

Una vez que te sientas cómodo creando componentes y manejando la reactividad básica, dale una oportunidad a Inertia. Entender ambos te convertirá en un desarrollador mucho más versátil.

En resumen:

• ¿Quieres velocidad y quedarte en PHP? Livewire.
• ¿Quieres el poder de Vue/React y una experiencia SPA total? Inertia.
• ¿Quieres terminar el proyecto hoy mismo? Probablemente Livewire.

Al final del día, lo más importante no es la herramienta, sino que te sientas cómodo usándola. ¡Instala ambos en proyectos de prueba y mira cuál te saca una sonrisa al programar!

Mi checklist rápido (decisión en 60 segundos)

Si respondes “sí” a varias de estas, ya tienes una pista:

• ¿Quiero minimizar JavaScript y trabajar mayormente con Blade? → Livewire
• ¿Mi UI depende de estado complejo y componentes frontend avanzados? → Inertia
• ¿Quiero mejorar solo algunas partes de una app existente? → Livewire
• ¿Mi equipo es más “frontend” y ya domina Vue/React/Svelte? → Inertia
• ¿Necesito SEO fácil sin montar SSR extra? → Livewire
• ¿Busco una experiencia SPA completa y extensible con librerías del ecosistema? → Inertia

Conclusión (mi consejo más honesto)

Cuando dos opciones son buenas, la decisión rara vez es “técnica pura”. Muchas veces es:

• productividad real,
• comodidad del equipo,
• y disfrute construyendo (sí, importa).

Mi recomendación práctica es la misma que yo aplico: arma una mini feature con ambas (una pantalla real, no “hola mundo”) y mide: ¿con cuál avanzas más rápido y con menos fricción?

Lo bueno: ambas son apuestas sólidas dentro de Laravel, con soporte y comunidad. Elijas la que elijas, puedes construir algo muy serio.

DE PHP 8.5 A LA IA GENERALISTA

Hace tres años, si me hubieran dicho que en 2026 estaría usando herramientas de IA para revisar mis pull requests y generar tests automáticamente, probablemente me hubiera reído. Pero aquí estamos, y el desarrollo web se ha transformado en algo que ni siquiera reconoceríamos hace una década.

Lo interesante es que, a pesar de toda esta evolución tecnológica, los fundamentos siguen siendo los mismos. Y si estás empezando o buscando consolidarte como desarrollador full-stack este año, hay algunas cosas que necesitas saber.

PHP EN 2026: MÁS VIVO QUE NUNCA

Sí, ya sé. PHP tiene mala reputación entre algunos desarrolladores que se quedaron con la imagen del lenguaje de hace 15 años. Pero PHP 8.5 es una bestia completamente diferente. Los tipos nativos, las propiedades readonly, los enums, y todo el ecosistema moderno han convertido PHP en un lenguaje que compite de tú a tú con cualquier otro.

Laravel, por su parte, sigue siendo mi framework preferido para proyectos que necesitan salir rápido sin sacrificar calidad. No es el framework más “cool” del mercado —ese título probablemente lo tenga alguna tecnología nueva cada tres meses—, pero es increíblemente productivo. Y en proyectos reales, con clientes reales y deadlines reales, la productividad vale más que la novedad.

Laravel Herd Pro: El Entorno Que No Sabías Que Necesitabas

Hablemos de algo que ha cambiado mi vida diaria: Laravel Herd Pro. Si has lidiado con Docker, Vagrant, Homestead, o cualquier otra solución para configurar tu entorno local, sabes el dolor que puede ser. Herd Pro eliminó todo eso.

Instalas, abres tu proyecto, y funciona. Sin configurar NGINX, sin problemas de permisos, sin preguntarte por qué el puerto 80 está ocupado otra vez. Tiene PHP switching incorporado, bases de datos, servicios de correo para testing… todo lo que necesitas sin la ceremonia.

No es una exageración decir que me ha ahorrado horas cada semana. Y esas horas las puedo usar para escribir código o, seamos honestos, para tomar otro café.

LOS FUNDAMENTOS NUNCA MUEREN

Hay algo que me sigue sorprendiendo cuando entrevisto developers: la cantidad de gente que sabe usar frameworks complejos pero no entiende por qué un array empieza en el índice 0.

La respuesta corta es: porque así funcionan los punteros en memoria. Cuando declaras un array, el nombre del array es básicamente un puntero a la primera posición de memoria. El índice es un offset —una distancia— desde ese punto inicial. Entonces, el primer elemento está a distancia 0 del inicio. El segundo está a distancia 1, y así sucesivamente.

¿Por qué importa esto? Porque entender cómo funciona la memoria te ayuda a escribir código más eficiente y a debuggear problemas que de otra forma parecerían magia negra.

Estructuras de Datos: El Arte de Organizar el Caos

En PHP moderno, trabajar con estructuras de datos complejas y anidadas es pan de cada día. APIs que retornan JSON con arrays dentro de objetos dentro de arrays… ya sabes de qué hablo.

Lo que he aprendido después de años lidiando con esto es que necesitas una estrategia clara. No se trata solo de usar array_map o collection->filter() —aunque son herramientas poderosas—, sino de pensar en cómo estructuras tus datos desde el principio.

Por ejemplo, cuando consumes una API externa, mi primer instinto es crear Data Transfer Objects (DTOs) simples que representen esa estructura. No estoy hablando de usar paquetes complejos ni soluciones over-engineered. A veces es solo una clase con propiedades públicas tipadas y un constructor que toma el array crudo. Pero esa capa de abstracción te salva cuando la API decide cambiar un campo o cuando necesitas transformar los datos para tu aplicación.

La clave está en encontrar el balance entre la simplicidad y la estructura. He visto proyectos que se vuelven imposibles de mantener porque todo es un array anidado sin tipo, y también he visto proyectos que se ahogan en su propia arquitectura porque cada estructura tiene 5 capas de abstracción.

EL ECOSISTEMA FRONT-END DE 2026: UN ZOOLÓGICO ORDENADO

Aquí es donde las cosas se ponen interesantes. El front-end moderno es un paisaje fragmentado, pero no de manera caótica como hace unos años. Las cosas se han estabilizado un poco.

React sigue siendo el rey, pero ya no es el React que conocías. Con Server Components y las mejoras en el ecosistema, se ha vuelto más parecido a los frameworks tradicionales del lado del servidor, pero con toda la interactividad del cliente cuando la necesitas. Next.js ha sido fundamental en esta transformación.

Hablando de Next.js, si vas a aprender un framework front-end este año y quieres algo que te dé trabajo inmediatamente, esta es tu mejor apuesta. El routing basado en archivos, la generación estática, el rendering del servidor, el middleware… es todo lo que necesitas para hacer aplicaciones complejas. Eso sí, la curva de aprendizaje puede ser empinada, especialmente si vienes del mundo tradicional de PHP + Blade templates.

Vue y su ecosistema (especialmente Nuxt) siguen siendo opciones sólidas. Personalmente, encuentro Vue más intuitivo que React si vienes de backend. La sintaxis es más limpia, menos “mágica” que JSX. Aunque debo admitir que el mercado laboral está más inclinado hacia React.

Y luego está Astro, que ha ganado muchísima tracción. La idea es simple pero poderosa: envía el mínimo JavaScript posible al navegador. Si estás construyendo contenido estático o sitios con poca interactividad, Astro es brillante. Puedes incluso mezclar componentes de React, Vue, o lo que sea dentro del mismo proyecto.

Como desarrollador full-stack que viene del lado de Laravel, mi recomendación es esta: aprende los fundamentos de JavaScript moderno primero. ES6+, async/await, promises, destructuring. Luego elige UN framework y profundiza. No intentes aprender todos al mismo tiempo.

Yo empecé con Vue porque la sintaxis me resultaba familiar, pero terminé trabajando más con React porque los proyectos lo demandaban. La verdad es que una vez que entiendes uno, los demás se vuelven más fáciles de aprender porque los conceptos fundamentales son los mismos.

CLOUDFLARE Y EL EDGE COMPUTING: EL PRESENTE, NO EL FUTURO

Si hay algo que ha cambiado mi forma de pensar sobre arquitectura en los últimos años, es el edge computing. Y Cloudflare está liderando eso de manera impresionante.

Cloudflare Workers te permite ejecutar código en más de 300 ubicaciones alrededor del mundo, más cerca de tus usuarios que cualquier servidor tradicional. La latencia se reduce drásticamente. Estamos hablando de respuestas en milisegundos, sin importar si tu usuario está en Tokio o en Buenos Aires.

Lo que más me gusta es que no es solo para casos de uso exóticos. Puedo usar Workers para hacer cosas prácticas: transformar imágenes al vuelo, cachear respuestas de API inteligentemente, ejecutar lógica de autenticación antes de que la request llegue a mi servidor principal, o incluso servir aplicaciones completas.

La integración con Laravel es sorprendentemente buena. Puedes tener tu aplicación principal en Laravel, pero usar Workers para manejar tareas específicas que necesitan estar en el edge. Por ejemplo, un endpoint de geolocalización que retorna contenido diferente según la ubicación del usuario, o un sistema de A/B testing que se ejecuta antes de que el HTML llegue al navegador.

Cloudflare Pages también merece una mención. Si estás usando alguno de esos frameworks front-end que mencioné antes, desplegar en Pages es ridículamente simple. Git push, y tu sitio está live. Con SSL, CDN global, y todo lo demás incluido.

LA IA EN EL DESARROLLO: HERRAMIENTA, NO REEMPLAZO

Seamos claros: GitHub Copilot, ChatGPT, y todas estas herramientas de IA no van a reemplazarte. Pero sí van a hacer que alguien que las usa sea más productivo que tú.

Yo uso IA todos los días. Para generar boilerplate, para revisar mi código, para escribir tests, para documentar funciones complejas. No le dejo escribir la lógica de negocio crítica, pero sí todo el código repetitivo que consume tiempo.

La clave es saber qué delegar y qué no. La IA es excelente para patrones comunes, terrible para contexto específico de negocio. Trátala como un junior developer muy rápido: puede hacer mucho trabajo pesado, pero necesita supervisión.

CONSEJOS PARA CRECER COMO FULL-STACK EN 2026

Después de todo esto, aquí está lo que realmente importa:

Primero, domina un stack completo antes de saltar a otro. Laravel + Vue o Laravel + React + MySQL + Cloudflare. Haz proyectos reales, no solo tutoriales. La diferencia entre saber usar un framework y saber construir con él solo la descubres cuando enfrentas problemas reales.

Segundo, aprende a leer código tanto como escribirlo. Los mejores developers que conozco pasan más tiempo leyendo que escribiendo. Clona repos populares, lee su código, entiende por qué tomaron ciertas decisiones.

Tercero, no menosprecies los fundamentos. Algoritmos, estructuras de datos, patrones de diseño. No necesitas memorizarlos todos, pero entender cuándo usar qué te separa de alguien que solo conoce frameworks.

Cuarto, construye en público. No tiene que ser open source complicado. Puede ser un blog técnico, responder preguntas en Stack Overflow, o compartir TILs (Today I Learned) en Twitter. Enseñar te obliga a entender profundamente.

Y finalmente, no te agobies. El desarrollo web es abrumador porque hay demasiado que aprender. Nadie sabe todo. Yo llevo años en esto y sigo aprendiendo cosas nuevas cada semana. La clave no es saberlo todo, sino saber aprender rápido cuando lo necesites.

El 2026 es un año increíble para ser desarrollador full-stack. Las herramientas nunca han sido mejores, la demanda nunca ha sido más alta, y las oportunidades para construir cosas geniales están por todas partes. Solo necesitas empezar, seguir aprendiendo, y no rendirte cuando las cosas se pongan difíciles (porque se van a poner difíciles, créeme).

CÓMO CONSUMIR LA API REST DE WORDPRESS DESDE ASTRO

WordPress incluye una API REST integrada que permite acceder a todo el contenido de forma programática. En este artículo aprenderás a consumir esta API desde Astro de manera simple y segura.

¿QUÉ ES WORDPRESS HEADLESS?

WordPress Headless es usar WordPress únicamente como gestor de contenido (CMS), mientras que el frontend se construye con otra tecnología, en este caso Astro. La comunicación entre ambos se realiza mediante la API REST de WordPress.

CONFIGURACIÓN INICIAL

1. Variables de Entorno

Crea un archivo .env.development para almacenar la URL de tu API:

API_URL=https://linen-antelope-447525.hostingersite.com/wp-json/wp/v2

Para producción, crea .env.production:

API_URL=https://tu-sitio-wordpress.com/wp-json/wp/v2

Astro cargará automáticamente el archivo correcto según el entorno.

VALIDACIÓN CON ZOD

Es fundamental validar los datos que vienen de la API. Zod es perfecto para esto y viene integrado con Astro.

Definir Schemas

Crea un archivo src/types/index.ts con los schemas:

import { z } from "astro:content";
​
// Schema base para contenido de WordPress
export const BaseWPSchema = z.object({
    id: z.number(),
    slug: z.string(),
    title: z.object({ rendered: z.string() }),
    content: z.object({ rendered: z.string() }),
});
​
// Schema para un post individual
export const PostItemSchema = BaseWPSchema.extend({
    date: z.string(),
    excerpt: z.object({ rendered: z.string() }),
});
​
// Schema para array de posts
export const PostsSchema = z.array(PostItemSchema);
​
// Tipo TypeScript exportado
export type Post = z.infer<typeof PostItemSchema>;

CONSUMIENDO LA API

Obtener Lista de Posts

En cualquier componente .astro, usa el frontmatter para hacer fetch:

---
import { PostsSchema } from "@/types";
​
const url = `${import.meta.env.API_URL}/posts`;
const response = await fetch(url);
const json = await response.json();
const posts = PostsSchema.safeParse(json);
​
if (!posts.success) {
    console.error("Error validando posts:", posts.error);
}
​
const validPosts = posts.success ? posts.data : [];
---
​
<div>
    {validPosts.map((post) => (
        <article>
            <h2 set:html={post.title.rendered} />
            <div set:html={post.excerpt.rendered} />
            <a href={`/blog/${post.slug}`}>Leer más</a>
        </article>
    ))}
</div>

Obtener Post Individual

Para páginas dinámicas, usa [slug].astro:

---
import { PostItemSchema } from "@/types";
​
export const prerender = false; // SSR activado
​
const { slug } = Astro.params;
const url = `${import.meta.env.API_URL}/posts?slug=${slug}`;
const response = await fetch(url);
const json = await response.json();
const post = PostItemSchema.safeParse(json[0]);
​
if (!post.success) {
    return Astro.redirect("/404");
}
​
const { title, content, date } = post.data;
---
​
<article>
    <h1 set:html={title.rendered} />
    <time>{date}</time>
    <div set:html={content.rendered} />
</article>

TRABAJANDO CON IMÁGENES

WordPress devuelve las imágenes destacadas en diferentes tamaños. Define un schema para validarlas:

const imageSchema = z.object({
    url: z.string().url(),
    width: z.number(),
    height: z.number(),
});
​
const featureImageSchema = z.object({
    thumbnail: imageSchema,
    medium: imageSchema,
    large: imageSchema,
    full: imageSchema,
});
​
export const PostItemSchema = BaseWPSchema.extend({
    featured_images: featureImageSchema.optional(),
});

Configurar Dominios Permitidos

En astro.config.mjs, permite las imágenes de WordPress:

export default defineConfig({
    image: {
        domains: ["tu-sitio-wordpress.com"]
    },
});

Usar las Imágenes en Componentes

---
import { Picture } from "astro:assets";
---
​
{post.featured_images?.full.url && (
    <Picture
        src={post.featured_images.full.url}
        alt={post.title.rendered}
        width={post.featured_images.full.width}
        height={post.featured_images.full.height}
        formats={["avif", "webp"]}
    />
)}

CUSTOM FIELDS CON ACF

Si usas Advanced Custom Fields, añade los campos personalizados al schema:

export const ProjectSchema = BaseWPSchema.extend({
    acf: z.object({
        url: z.string().url(),
        github_repo: z.string().optional(),
    }),
    technologies: z.array(z.string()),
});

Accede a ellos normalmente:

---
const { acf, technologies } = project;
---
​
<a href={acf.url}>Ver Proyecto</a>
<ul>
    {technologies.map(tech => <li>{tech}</li>)}
</ul>

ENDPOINTS COMUNES

La API REST de WordPress ofrece varios endpoints:

• /posts – Artículos del blog

• /pages – Páginas

• /categories – Categorías

• /tags – Etiquetas

• /media – Archivos multimedia

• /users – Usuarios

Todos siguen el mismo patrón de consumo.

MEJORES PRÁCTICAS

1. Siempre valida con Zod: Usa .safeParse() en lugar de .parse() para manejar errores gracefully.

2. Maneja errores: Redirige a 404 o muestra mensajes apropiados cuando falle la validación.

3. Usa SSR cuando sea necesario: Añade export const prerender = false en páginas que necesiten datos en tiempo real.

4. Tipado fuerte: Exporta tipos desde tus schemas con z.infer<> para aprovechar TypeScript.

5. Variables de entorno: Nunca hardcodees URLs de APIs, usa variables de entorno.