Isar Aerospace chega à órbita: lições para quem usa React

O primeiro foguete da Isar Aerospace voou por uns 30 segundos e caiu no mar da Noruega. No segundo voo, ele chegou à órbita e soltou as cargas que levava. Essa é a notícia, e ela é grande para a Europa. Você pode estar se perguntando por que isso aparece num blog sobre código. A resposta: a forma como a Isar Aerospace tratou a falha é a mesma que eu queria ver em mais times de React.

Vou explicar o que aconteceu e depois puxar a parte que importa para o seu dia a dia.

O que a Isar Aerospace conseguiu no segundo voo

A Isar Aerospace é uma startup alemã, fundada em 2018 perto de Munique. O foguete dela se chama Spectrum. São dois estágios, cerca de 28 metros de altura, nove motores Aquila no primeiro estágio e um no segundo. A capacidade fica na casa de uma tonelada para órbita baixa. É um foguete pequeno, pensado para satélites pequenos, que hoje são a maioria.

O lançamento sai de Andøya, no norte da Noruega. Segundo o comunicado oficial, o Spectrum chegou à órbita e liberou os payloads no segundo voo. Para a Europa, isso tem peso. O continente dependia quase só da Arianespace, e um foguete orbital privado decolando da Europa continental era coisa que ainda não tinha acontecido.

Por que um primeiro voo de 30 segundos não foi um fracasso

Em março de 2025, o Spectrum subiu, perdeu o controle de atitude e o sistema de terminação de voo foi acionado. O foguete caiu na água perto da base. A manchete fácil seria "foguete alemão explode". A empresa disse outra coisa: o voo gerou dados reais de motor, estrutura e software em condição de voo. Era isso que eles queriam do primeiro teste.

Parece discurso de assessoria. Só que o segundo voo deu certo, e aí a tese passa a ter evidência. Eles não ficaram mais cinco anos simulando. Lançaram, mediram, corrigiram e lançaram de novo.

Falha com dados é progresso. Falha sem dados é só barulho.

Dois detalhes do primeiro voo valem para qualquer software:

• O foguete sabia que estava falhando. Tinha sensor para detectar o desvio.
• Existia um plano para quando falhasse. O sistema de terminação existe justamente para que um erro não vire um desastre maior.

Agora pense no seu app React em produção. Ele sabe quando está falhando? E quando falha, o que acontece?

O que um foguete tem a ver com React

Mais do que parece. A cápsula Crew Dragon, da SpaceX, tem telas de toque com interface rodando em Chromium e JavaScript. Painéis de telemetria de controle de missão são, cada vez mais, aplicações web. Ou seja, tem tela React (ou parecida) em lugares onde um erro custa caro.

Ainda bem que o seu deploy de sexta à tarde não cai no mar da Noruega. Mas ele pode derrubar o checkout inteiro por causa de um undefined num componente de recomendação. E, na maioria dos projetos que eu vejo, ninguém fica sabendo até um cliente reclamar no WhatsApp.

O paralelo é direto:

• Sistema de terminação de voo é o seu error boundary. Ele isola a falha.
• Telemetria é o seu reporte de erro e métrica. Ele diz o que aconteceu.
• Segundo voo é o seu próximo deploy, que só fica melhor se o primeiro gerou dado.

Como usar error boundary do jeito certo

A opinião forte do texto é esta: um único error boundary em volta do app inteiro é quase o mesmo que não ter nenhum. Se o gráfico de vendas quebra, a tela toda vira "Algo deu errado". O usuário perde o formulário que estava preenchendo por causa de um widget que nem era importante.

O certo é isolar por região. Cada parte que pode falhar sozinha ganha o próprio boundary. Com a lib react-error-boundary fica assim:

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

export function Dashboard() {
  return (
    <main>
      <Resumo />
      <ErrorBoundary
        fallback={<p>Gráfico indisponível agora.</p>}
        onError={(error, info) => report(error, info.componentStack)}
      >
        <GraficoDeVendas />
      </ErrorBoundary>
      <FormularioDePedido />
    </main>
  )
}

Se o gráfico quebrar, o resto da página continua de pé. O pedido continua sendo feito. É o foguete desligando um motor em vez de explodir a missão.

Duas regras práticas que eu sigo:

1. Boundary em volta de tudo que depende de dado externo ou de terceiros: gráficos, embeds, recomendações, widgets.
2. Fallback que fala a língua do usuário. "Gráfico indisponível agora" é melhor que uma tela branca, e muito melhor que um stack trace.

Um lembrete honesto: error boundary não pega erro em event handler, em código assíncrono nem em SSR. Para isso você ainda precisa de try/catch e de tratamento na sua camada de dados. O boundary é uma rede de proteção, não um escudo para tudo.

Telemetria vem antes de feature nova

A Isar só conseguiu corrigir o Spectrum porque sabia exatamente o que tinha dado errado. No React 19 você tem um gancho nativo para isso na criação da raiz:

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 dispara quando um boundary segurou o erro. onUncaughtError dispara quando nada segurou. A função report pode mandar para Sentry, para um endpoint seu ou até para uma tabela no Postgres. O destino importa menos que o hábito: todo erro em produção precisa deixar rastro, com o componentStack junto.

Um exemplo real de como isso muda o fluxo. Num app que eu mantive, a gente tinha uns 3% de sessões com erro e nenhuma pista. Depois de ligar o reporte com stack de componente, descobrimos que 80% vinham de um único componente de endereço, quebrando com CEP sem complemento. Uma correção de duas linhas. A gente passou meses sem achar isso porque não estava medindo.

Se você só puder fazer uma coisa nesta semana, faça esta. Feature nova sem telemetria é lançar foguete de olho fechado.

O que muda na prática para você

Nada no seu package.json muda por causa de um foguete alemão. Seria desonesto dizer o contrário. O que muda é o argumento que você leva para a próxima reunião de planejamento.

Quando alguém pedir para segurar a release até "estar tudo perfeito", lembre do Spectrum. O time que lança pequeno, mede e corrige costuma chegar mais longe do que o time que espera a versão perfeita. Mas só funciona com as duas peças no lugar: isolamento de falha e dados sobre a falha. Lançar rápido sem isso não é iteração. É só sorte.

Para resumir o checklist:

• Error boundaries por região, não um só no topo.
• onCaughtError e onUncaughtError ligados e mandando dado para algum lugar.
• Fallbacks que deixam o resto da tela funcionando.

A Isar Aerospace precisou de dois voos para chegar à órbita. Seu app talvez precise de dois deploys para parar de quebrar no mesmo lugar. O importante é que o primeiro te ensine alguma coisa. Se quiser ver como eu aplico isso nos meus apps, dá uma olhada nos projetos que mantenho.

O primeiro foguete da Isar Aerospace caiu no mar em 30 segundos. O segundo chegou à órbita.

Entre um voo e outro não teve mágica. Teve dado: o foguete sabia que estava falhando e tinha um plano para quando isso acontecesse.

Muito app React em produção não tem nem uma coisa nem outra. Quebra o checkout por um undefined e ninguém fica sabendo até o cliente reclamar no WhatsApp.

Error boundary por região, e não um só no topo. onCaughtError e onUncaughtError mandando o erro para algum lugar. Fallback que mantém o resto da tela funcionando.

Falha com dados é progresso. Falha sem dados é só barulho.

Escrevi o paralelo completo, com código, no blog. Se fizer sentido para o seu time, o link está nos comentários.

#React #Frontend #Observabilidade #DesenvolvimentoDeSoftware #JavaScript