El cliente consume su propia API · Lenguaje de marcas

Hoy · Hoja de ruta

1. Aprende: Cómo se conecta el cliente de la UD4 con la API propia, y qué cambia respecto a una ajena.
2. Haz: Sustituye los datos de ejemplo por llamadas reales a tu API.
3. Comprueba: La aplicación funciona de punta a punta y trata los cuatro estados.

Antes de empezar · 5 minutos, sin apuntes

¿Por qué ahora no tendrás problemas de CORS?
¿Qué cuatro estados tenía que contemplar una carga?
Si el servidor devuelve 400 con detalles, ¿qué debe hacer tu interfaz?

El mismo origen

Como el cliente se sirve desde el mismo servidor que la API, las peticiones son relativas y no cruzan de origen:

const productos = await pedir("/api/productos");

Sin dominio, sin puerto y sin CORS. Es una de las razones prácticas de servir ambas cosas juntas mientras el proyecto es pequeño.

Filtrar: ¿en el cliente o en el servidor?

Dónde	Cuándo conviene
En el cliente	Pocos datos, ya descargados: respuesta instantánea
En el servidor	Muchos datos, o filtros que dependen de reglas o permisos

Una decisión de diseño, no una preferencia

Con doscientos productos, descargarlos una vez y filtrar en el navegador es mejor experiencia: no hay espera. Con doscientos mil, o cuando el filtro depende de quién pregunta, la única opción es el servidor.

Lo que no vale es hacerlo en los dos sitios con reglas distintas: entonces el mismo filtro da resultados diferentes según por dónde pase, y ese fallo es dificilísimo de encontrar.

Toma la decisión, escríbela en tus notas y sé coherente.

Los cuatro estados, ahora de verdad

El estado que montaste en la UD4 ya tenía sitio para cargando y error. Ahora esos campos dejan de ser una simulación:

async function cargar() {
  estado.cargando = true;
  estado.error = null;
  actualizar();

  try {
    estado.productos = await pedir("/api/productos");
  } catch (error) {
    estado.error = error.mensaje;
  } finally {
    estado.cargando = false;
    actualizar();
  }
}

Tarea 11 · Conectar

Sustituye los datos escritos a mano por una llamada a tu API.
Usa la función pedir de la sesión 9 para todas las llamadas.
Decide dónde filtras y déjalo escrito.
Comprueba los cuatro estados apagando el servidor y simulando red lenta.
Añade el botón de reintentar.
Comprueba que la primera carga llega renderizada del servidor y el cliente la toma desde ahí.

Objetivo mínimoInterfaz completa alimentada por tu API, con los cuatro estados.

Si lo tienesFiltra en el servidor y comprueba en Network qué se envía.

RetoHaz que la primera carga no repita la petición de lo que ya llegó renderizado.

Checkpoint · fin de la sesión 11

El cliente consume tu API con rutas relativas.
Una sola función trata todas las respuestas y errores.
Los cuatro estados se ven de verdad.
Has decidido y documentado dónde se filtra.

Ver respuestas

1 · Porque cliente y API comparten origen.

2 · Cargando, error, vacío y datos.

3 · Mostrar los detalles del error junto a los campos que los provocaron.