Isar Aerospace llega a la órbita: lecciones para quien usa React

El primer cohete de Isar Aerospace voló unos 30 segundos y cayó al mar de Noruega. En el segundo vuelo llegó a la órbita y liberó las cargas que llevaba. Esa es la noticia, y es grande para Europa. Quizás te preguntes por qué aparece en un blog sobre código. La respuesta: la forma en que Isar Aerospace trató el fallo es la misma que me gustaría ver en más equipos de React.

Voy a explicar qué pasó y después sacar la parte que importa para tu día a día.

Lo que Isar Aerospace logró en el segundo vuelo

Isar Aerospace es una startup alemana, fundada en 2018 cerca de Múnich. Su cohete se llama Spectrum. Tiene dos etapas, unos 28 metros de altura, nueve motores Aquila en la primera etapa y uno en la segunda. Su capacidad ronda una tonelada a órbita baja. Es un cohete pequeño, pensado para satélites pequeños, que hoy son la mayoría.

El lanzamiento sale de Andøya, en el norte de Noruega. Según el comunicado oficial, el Spectrum llegó a la órbita y liberó los payloads en el segundo vuelo. Para Europa, esto tiene peso. El continente dependía casi solo de Arianespace, y un cohete orbital privado despegando desde la Europa continental era algo que todavía no había pasado.

Por qué un primer vuelo de 30 segundos no fue un fracaso

En marzo de 2025, el Spectrum despegó, perdió el control de actitud y se activó el sistema de terminación de vuelo. El cohete cayó al agua cerca de la base. El titular fácil sería "cohete alemán explota". La empresa dijo otra cosa: el vuelo generó datos reales de motor, estructura y software en condiciones de vuelo. Eso era lo que querían del primer intento.

Suena a discurso de prensa. Pero el segundo vuelo salió bien, y ahí la tesis pasa a tener evidencia. No se quedaron cinco años más simulando. Lanzaron, midieron, corrigieron y volvieron a lanzar.

Fallar con datos es progreso. Fallar sin datos es solo ruido.

Dos detalles del primer vuelo valen para cualquier software:

• El cohete sabía que estaba fallando. Tenía sensores para detectar la desviación.
• Había un plan para cuando fallara. El sistema de terminación existe justamente para que un error no se convierta en un desastre mayor.

Ahora piensa en tu app React en producción. ¿Sabe cuándo está fallando? Y cuando falla, ¿qué pasa?

Qué tiene que ver un cohete con React

Más de lo que parece. La cápsula Crew Dragon, de SpaceX, tiene pantallas táctiles con una interfaz que corre en Chromium y JavaScript. Los paneles de telemetría del control de misión son, cada vez más, aplicaciones web. O sea, hay pantallas en React (o algo parecido) en lugares donde un error sale caro.

Por suerte, tu deploy del viernes por la tarde no cae al mar de Noruega. Pero sí puede tumbar todo el checkout por un undefined en un componente de recomendaciones. Y en la mayoría de los proyectos que veo, nadie se entera hasta que un cliente se queja por WhatsApp.

El paralelo es directo:

• El sistema de terminación de vuelo es tu error boundary. Aísla el fallo.
• La telemetría es tu reporte de errores y métricas. Te dice qué pasó.
• El segundo vuelo es tu próximo deploy, que solo mejora si el primero generó datos.

Cómo usar error boundaries de la forma correcta

La opinión fuerte del texto es esta: un único error boundary alrededor de toda la app es casi lo mismo que no tener ninguno. Si el gráfico de ventas se rompe, toda la pantalla pasa a "Algo salió mal". El usuario pierde el formulario que estaba llenando por culpa de un widget que ni siquiera era importante.

Lo correcto es aislar por región. Cada parte que puede fallar por su cuenta tiene su propio boundary. Con la librería react-error-boundary queda así:

import { ErrorBoundary } from 'react-error-boundary'

export function Dashboard() {
  return (
    <main>
      <Resumen />
      <ErrorBoundary
        fallback={<p>Gráfico no disponible por ahora.</p>}
        onError={(error, info) => report(error, info.componentStack)}
      >
        <GraficoDeVentas />
      </ErrorBoundary>
      <FormularioDePedido />
    </main>
  )
}

Si el gráfico se rompe, el resto de la página sigue en pie. El pedido se sigue haciendo. Es el cohete apagando un motor en lugar de hacer explotar la misión.

Dos reglas prácticas que sigo:

1. Boundary alrededor de todo lo que depende de datos externos o de terceros: gráficos, embeds, recomendaciones, widgets.
2. Un fallback que hable el idioma del usuario. "Gráfico no disponible por ahora" es mejor que una pantalla en blanco, y mucho mejor que un stack trace.

Un recordatorio honesto: el error boundary no captura errores en event handlers, en código asíncrono ni en SSR. Para eso todavía necesitas try/catch y manejo de errores en tu capa de datos. El boundary es una red de seguridad, no un escudo para todo.

La telemetría va antes que la nueva feature

Isar solo pudo corregir el Spectrum porque sabía exactamente qué había fallado. En React 19 tienes un hook nativo para esto al crear la raíz:

import { createRoot } from 'react-dom/client'

const root = createRoot(document.getElementById('root')!, {
  onCaughtError: (error, info) =>
    report('caught', error, info.componentStack),
  onUncaughtError: (error, info) =>
    report('uncaught', error, info.componentStack),
})

root.render(<App />)

onCaughtError se dispara cuando un boundary atrapó el error. onUncaughtError se dispara cuando nada lo atrapó. La función report puede enviarlo a Sentry, a un endpoint tuyo o incluso a una tabla en Postgres. El destino importa menos que el hábito: todo error en producción tiene que dejar rastro, con el componentStack incluido.

Un ejemplo real de cómo esto cambia el flujo. En una app que mantuve, teníamos cerca de un 3% de sesiones con error y ninguna pista. Después de activar el reporte con el stack de componentes, descubrimos que el 80% venía de un solo componente de dirección, que se rompía con códigos postales sin complemento. Una corrección de dos líneas. Pasamos meses sin encontrarlo porque no estábamos midiendo.

Si esta semana solo puedes hacer una cosa, haz esta. Una feature nueva sin telemetría es lanzar un cohete con los ojos cerrados.

Qué cambia en la práctica para ti

Nada en tu package.json cambia por un cohete alemán. Sería deshonesto decir lo contrario. Lo que cambia es el argumento que llevas a la próxima reunión de planificación.

Cuando alguien pida frenar la release hasta que "todo esté perfecto", acuérdate del Spectrum. El equipo que lanza en pequeño, mide y corrige suele llegar más lejos que el equipo que espera la versión perfecta. Pero solo funciona con las dos piezas en su lugar: aislamiento de fallos y datos sobre el fallo. Lanzar rápido sin eso no es iterar. Es pura suerte.

Para resumir el checklist:

• Error boundaries por región, no uno solo arriba de todo.
• onCaughtError y onUncaughtError activados y enviando datos a algún lugar.
• Fallbacks que dejan el resto de la pantalla funcionando.

Isar Aerospace necesitó dos vuelos para llegar a la órbita. Tu app quizás necesite dos deploys para dejar de romperse en el mismo lugar. Lo importante es que el primero te enseñe algo. Si quieres ver cómo aplico esto en mis apps, échale un vistazo a los proyectos que mantengo.

El primer cohete de Isar Aerospace cayó al mar en 30 segundos. El segundo llegó a la órbita.

Entre un vuelo y otro no hubo magia. Hubo datos: el cohete sabía que estaba fallando y tenía un plan para cuando eso pasara.

Muchas apps React en producción no tienen ni lo uno ni lo otro. El checkout se rompe por un undefined y nadie se entera hasta que el cliente se queja por WhatsApp.

Un error boundary por región, y no uno solo arriba de todo. onCaughtError y onUncaughtError enviando el error a algún lugar. Un fallback que mantiene el resto de la pantalla funcionando.

Fallar con datos es progreso. Fallar sin datos es solo ruido.

Escribí el paralelo completo, con código, en el blog. Si le sirve a tu equipo, el enlace está en los comentarios.

#React #Frontend #Observabilidad #DesarrolloDeSoftware #JavaScript