Tempo real no app React Native: WebSocket, polling e sync sem caos

Todo app corporativo chega em algum ponto na mesma pergunta: "precisamos de tempo real?". A lista de desejos aparece rapido: pendencia nova sem atualizar a tela, status de aprovacao mudando na hora, fila sincronizada, badge vivo, operador acompanhando processo sem ficar puxando para baixo toda hora. O problema e que "tempo real" costuma virar uma palavra unica para tecnicas bem diferentes, com custos bem diferentes.

No mobile, escolher errado pesa mais. Conexao cai, o app vai para background, a pessoa troca de rede, o servidor manda mais evento do que a tela consegue consumir, o push acorda o interesse, mas nao substitui uma sessao viva, e o refresh automático pode fazer mais sentido do que uma conexao aberta o tempo inteiro.

Este artigo organiza um caminho pratico para React Native corporativo: quando usar WebSocket, quando polling ainda e a escolha mais madura e como costurar AppState, estado de rede e cache para manter a experiencia coerente sem montar um castelo fragil.

1. Tempo real nao significa automaticamente WebSocket

O primeiro ajuste mental e separar necessidade de negocio de tecnologia de transporte. Nem toda tela que "precisa atualizar" pede uma conexao bidirecional aberta. Em varios casos, o que o produto realmente precisa e:

• recarregar dados ao voltar para o app;
• refazer consulta quando a tela ganha foco;
• mostrar uma notificacao quando algo importante muda;
• fazer polling curto durante um fluxo transitorio;
• usar WebSocket apenas onde a latencia realmente faz diferenca.

Quando a equipe pula direto para socket em toda parte, a arquitetura vira uma mistura de conexoes, reconexoes, listeners duplicados e bugs de tela que ninguem sabe se vieram da API, da rede ou da navegacao.

2. React Native tem WebSocket global, mas isso nao encerra a decisao

A documentacao do React Native registra a existencia da classe global WebSocket e ainda avisa que a pagina esta em progresso, recomendando consultar a documentacao da MDN para mais detalhes de comportamento. Em outras palavras: o runtime suporta a API, mas o desenho de uso continua dependendo do contrato geral do WebSocket.

A MDN define o WebSocket como a API para criar e gerenciar uma conexao com um servidor e enviar ou receber dados nessa conexao. O ponto importante para arquitetura esta na mesma pagina: a API nao oferece mecanismo de backpressure. Se as mensagens chegarem mais rapido do que a aplicacao consegue processar, o app pode acumular memoria, ficar com uso alto de CPU ou travar.

Esse detalhe derruba uma fantasia comum. WebSocket nao e um selo automatico de arquitetura moderna. Ele e uma ferramenta boa quando o ritmo de evento, o modelo de consumo e o valor do dado em tempo real realmente justificam o custo.

3. Onde WebSocket costuma fazer sentido no app corporativo

Em produto corporativo, WebSocket tende a brilhar quando a interface precisa reagir a mudancas curtas e frequentes enquanto a pessoa esta olhando para aquela tela. Exemplos razoaveis:

• atualizacao de status de atendimento ou aprovacao em andamento;
• painel operacional com fila pequena e eventos novos chegando durante a sessao ativa;
• feed de alteracoes em processo colaborativo sensivel a atraso curto;
• presenca ou disponibilidade quando isso muda a acao imediata da pessoa usuaria.

Nesses cenarios, o ganho de reatividade aparece na experiencia. A tela fica viva sem depender de refresh manual a cada passo.

4. Onde WebSocket costuma ser exagero

Nem todo dado mutavel pede uma conexao aberta. Varios fluxos funcionam melhor com estrategia mais simples:

• lista que pode ser atualizada ao entrar na tela;
• processo em background cujo resultado pode aparecer por push ou na proxima consulta;
• status que muda poucas vezes por dia;
• dados que ja passam por fila local, retry e reconciliacao de API.

Se a mudanca nao precisa chegar em segundos, muitas vezes polling controlado ou refetch por foco entrega experiencia suficiente com menos acoplamento operacional.

5. Polling nao e atraso tecnico; em muitos casos e maturidade

Polling fica com fama injusta porque muita equipe lembra apenas de implementacoes agressivas e desperdicadoras. Mas polling bem desenhado continua muito util quando:

• o backend ainda nao expoe stream ou canal socket maduro;
• o volume de mudanca e baixo ou previsivel;
• o dado importa apenas enquanto a tela esta aberta;
• o app precisa de previsibilidade maior do que uma conexao longa instavel ofereceria;
• o fluxo ja usa cache e invalidação orientada por evento interno.

Para time pequeno, polling curto durante uma tela critica costuma ser mais facil de testar, observar e desligar do que uma malha de socket espalhada no aplicativo inteiro.

6. AppState muda a estrategia de atualizacao

A documentacao oficial do React Native explica que AppState informa se o app esta em active, background ou, no iOS, inactive. A mesma pagina diz que ele e frequentemente usado para determinar o comportamento correto ao lidar com push notifications.

Isso tem consequencia direta para tempo real: quando o app sai da frente, a estrategia nao precisa continuar igual. Em muitos produtos, vale mais:

• reduzir ou pausar atualizacao viva no background;
• reconciliar estado ao voltar para active;
• usar push para sinalizar interesse, e nao manter tudo aberto cegamente;
• tratar Android blur e focus com cuidado em telas sensiveis.

Tempo real maduro no mobile respeita ciclo de vida. Ele nao assume que a sessao vai ficar ativa e perfeita como em dashboard web sempre aberto.

7. Estado de rede real importa mais do que uma reconexao otimista

A documentacao do Expo Network oferece duas pecas bem uteis aqui. A primeira e getNetworkStateAsync(), que retorna informacoes como isConnected e isInternetReachable. A segunda e addNetworkStateListener(), que permite reagir a mudancas da rede.

O mesmo documento faz uma distincao importante: isConnected nao significa automaticamente internet realmente alcancavel. Em iOS, esse valor sempre acompanha isConnected; em Android, existe uma verificacao mais especifica de reachability.

Na pratica, isso ajuda a evitar uma classe chata de bug: o app acha que "voltou a rede", dispara refresh, reabre socket e tenta sincronizar tudo ao mesmo tempo, quando a conectividade ainda esta oscilando ou sem saida real para internet.

8. TanStack Query mostra um caminho muito maduro para refetch mobile

A documentacao do TanStack Query para React Native traz duas recomendacoes especialmente boas. A primeira e ligar o onlineManager ao estado de rede, seja com NetInfo ou com expo-network. O exemplo oficial com Expo usa addNetworkStateListener() e um getNetworkStateAsync() inicial para definir online/offline de forma consistente.

A segunda recomendacao e usar o AppState para alimentar o focusManager. O proprio exemplo oficial mostra AppState.addEventListener('change', ...) chamando focusManager.setFocused(status === 'active'), de modo que o app atualize consultas quando volta a ficar ativo.

Esse desenho resolve uma porcao de "tempo real suficiente" sem abrir socket nenhum. Em vez de tentar viver conectado o tempo todo, a tela volta com dados mais frescos no momento de uso real.

9. Refetch por foco de tela costuma valer mais do que socket global

Na mesma documentacao, o TanStack Query mostra um hook de exemplo com useFocusEffect para refazer queries stale quando a screen recebe foco novamente. Isso e muito util em app com navegacao por abas, stacks e retornos curtos de fluxo.

Para varios cenarios corporativos, esse padrao entrega melhor custo-beneficio do que um socket global:

• a pessoa entra na tela e recebe dado atual;
• sai para outro fluxo e nao deixa listener sobrando;
• volta e refaz apenas o que esta stale;
• o app gasta menos energia e menos engenharia de reconexao.

Quando a necessidade de tempo real e local a uma ou duas telas, isso geralmente respira melhor do que espalhar conexao viva em todo o shell do app.

10. WebSocket, push e background nao sao a mesma coisa

Um erro comum e misturar tres camadas diferentes:

• WebSocket para atualizacao viva enquanto a sessao esta ativa;
• push para avisar evento relevante fora da tela atual ou fora do app;
• background task para trabalho diferido quando a plataforma permitir.

O portal ja cobre essas outras partes em push no app e background task. O ponto aqui e manter fronteiras claras. Push nao substitui stream de tela ativa. WebSocket nao substitui fila de sincronizacao diferida. Background task nao e motor de tempo real.

11. O backend precisa ajudar a nao transformar realtime em bagunca

Mesmo quando o app escolhe WebSocket, a API e o servidor precisam colaborar com parcimonia. Como a MDN alerta para falta de backpressure na API, o servidor nao deveria despejar tudo sem criterio no cliente. Em app corporativo, costuma funcionar melhor:

• enviar eventos pequenos e bem tipados;
• evitar payload gigante repetido em toda mudanca;
• usar IDs e timestamps claros para reconciliacao;
• permitir refetch consistente da entidade quando o estado local desconfiar do stream;
• manter fallback HTTP simples para recuperar consistencia.

Em outras palavras: realtime bom quase sempre depende de uma API que sabe ser consultada de novo sem drama.

12. Uma estrategia pragmatica para o app corporativo

Em vez de decidir por tecnologia unica, um caminho maduro costuma ser este:

1. usar TanStack Query com onlineManager e focusManager para a base de leitura;
2. usar refetch por foco para telas que so precisam voltar atualizadas;
3. usar polling curto quando a pessoa espera um status mudar dentro de um fluxo aberto;
4. reservar WebSocket para telas em que evento frequente e valor imediato justificam a conexao viva;
5. usar push para trazer a pessoa de volta ao contexto certo quando ela nao esta na tela.

Esse arranjo reduz heroismo tecnico. Cada camada faz o trabalho que realmente encaixa no comportamento mobile.

13. Checklist rapido para decidir

1. O dado precisa chegar em segundos ou basta voltar atualizado ao foco?
2. A pessoa esta olhando a tela quando a mudanca acontece?
3. O servidor aguenta stream de eventos pequeno e bem filtrado?
4. Existe fallback HTTP simples para reconciliar o estado?
5. O app sabe pausar ou reduzir estrategia ao sair de active?
6. O estado de rede esta sendo observado antes de reconectar ou refazer queries?
7. Push resolveria melhor a descoberta do evento do que socket permanente?
8. Polling controlado entregaria o mesmo valor com custo menor?

14. Quando vale um diagnostico tecnico

Se hoje o time esta discutindo socket para tudo, se a tela recebe dado duplicado, se a volta do background cria avalanche de refetch, se a reconexao vive brigando com offline e push, provavelmente o problema nao e uma biblioteca especifica. Falta estrategia de sincronizacao ativa no app. Nessa hora, um diagnostico tecnico ajuda a desenhar fronteiras entre stream, polling, cache, fila local e API antes que o mobile cresca como uma colcha de listeners sem dono.

Tempo real maduro em React Native nao e a tela que se mexe mais. E a tela que se atualiza no ritmo certo, com o custo certo e com um plano claro quando a rede, o foco ou a plataforma deixam de colaborar.

Referencias editoriais: React Native - WebSocket, MDN - WebSocket, React Native - AppState, Expo - Network e TanStack Query - React Native.