Resumo Executivo

Gabriela Maria Pereira Gonzaga; Ariel Da Silva Dias

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A intensificação do uso de dados e o avanço acelerado da transformação digital no cenário contemporâneo conferiram aos dashboards em tempo real um papel fundamental dentro das estruturas industriais modernas. Essas ferramentas consolidaram-se como instrumentos indispensáveis para o acompanhamento contínuo de indicadores de desempenho, fundamentando processos críticos de tomada de decisão em níveis operacionais e táticos. A integração eficiente entre a coleta de informação e a visualização imediata fortalece a agilidade organizacional, ampliando a capacidade de resposta diante de variáveis críticas que podem comprometer o fluxo produtivo (Alarcón e Vásquez, 2021). No contexto da Indústria 4.0, a monitorização de métricas como a Eficiência Global dos Equipamentos, comumente referida como OEE, exige sistemas que operem com alta fidelidade e baixa latência, uma vez que atrasos na percepção de falhas resultam em prejuízos financeiros diretos e subutilização de ativos (Soares, 2023).

O desenvolvimento de interfaces modernas e responsivas encontrou no ecossistema ReactJS uma base sólida, especialmente devido aos conceitos de componentização e ao uso do Document Object Model virtual, que otimizam a eficiência nos processos de renderização (Kainu, 2022). Tais características são vitais para dashboards industriais que demandam atualizações constantes sem comprometer a estabilidade do navegador do usuário. Estudos indicam que aplicações construídas com essa tecnologia, quando devidamente configuradas, sustentam fluxos de dados em tempo real com desempenho superior a pilhas tecnológicas tradicionais, como a combinação entre PHP e bancos de dados relacionais convencionais (Hyseni et al., 2023). Entretanto, a eficácia dessas interfaces depende intrinsecamente do protocolo de comunicação estabelecido entre o cliente e o servidor, sendo este o ponto de maior fricção em ambientes de alta demanda.

A motivação para o aprofundamento técnico nesta área decorre de desafios observados em ambientes corporativos reais, onde a utilização de modelos baseados em requisições periódicas via Representational State Transfer, o padrão REST, frequentemente apresenta limitações severas. Em cenários de monitoramento de produção, a configuração de atualizações em intervalos fixos, como a cada cinco minutos, gera lacunas informacionais que prejudicam a confiabilidade do sistema e a experiência do usuário. A literatura técnica ressalta que a aplicação do OEE exige métodos de coleta e atualização que sejam plenamente compatíveis com a dinâmica acelerada do chão de fábrica (South American Development Society Journal, 2018). Para superar tais barreiras, a substituição do modelo de consulta cíclica pelo uso de WebSockets, protocolo definido pela RFC 6455, surge como uma alternativa capaz de manter um canal de comunicação bidirecional e contínuo (Fette e Melnikov, 2011).

Embora o uso de WebSockets prometa ganhos visíveis em responsividade e redução de latência, a implementação em larga escala revela fragilidades estruturais em situações comuns do cotidiano fabril, como instabilidades de rede, bloqueios de tela ou hibernação de terminais de consulta. Nessas condições, a queda da conexão interrompe o fluxo de dados, exigindo mecanismos robustos de verificação e reconexão automática para garantir que o dashboard não apresente informações obsoletas (Pautasso e Wilde, 2014). Diante dessa dualidade tecnológica, torna-se imperativo comparar o desempenho, a estabilidade e a escalabilidade das APIs REST e dos WebSockets sob diferentes condições de carga, identificando as melhores práticas de configuração que permitam otimizar tanto a performance técnica quanto a percepção de valor pelo usuário final.

A metodologia adotada para a realização deste estudo possui caráter aplicado e experimental, concentrando-se na mensuração rigorosa de métricas de latência e consumo de recursos. Os experimentos foram conduzidos em um ambiente controlado para assegurar a reprodutibilidade dos achados, utilizando um hardware composto por processador AMD Ryzen 7 5700G com frequência de 3.80 GHz, 16 GB de memória RAM e sistema operacional Windows 10 de 64 bits. No lado do servidor, utilizou-se o ambiente de execução Node.js na versão 22.13.1 em conjunto com o framework Express, responsável por disponibilizar tanto os endpoints REST quanto os canais de comunicação via WebSocket. O desenvolvimento do frontend foi realizado com ReactJS na versão 19.1.1, utilizando a ferramenta Vite para o empacotamento e otimização dos ativos digitais.

Para o modelo baseado em REST, foram integradas as bibliotecas Axios e React Query, enquanto o modelo WebSocket utilizou socket.io-client e a biblioteca STOMP.js, apoiados por um broker configurado no backend. A avaliação do desempenho da interface foi executada por meio do Google Lighthouse, ferramenta que fornece indicadores padronizados como o First Contentful Paint, o Largest Contentful Paint, o Total Blocking Time, o Cumulative Layout Shift e o Speed Index. O uso dessa ferramenta garantiu que as medições fossem consistentes e comparáveis entre os diversos cenários de teste propostos. Para assegurar a equidade nas comparações, ambos os protocolos processaram a mesma base de dados sintética gerada pela biblioteca Faker, simulando métricas típicas de OEE, incluindo histórico de produção, ordens em andamento, eventos de parada e registros de refugo.

O detalhamento operacional dos testes envolveu a simulação de volumes de dados variando entre 500 KB e 1,2 MB por mensagem ou requisição. Em cenários de estresse, essa carga foi ampliada em duas e quatro vezes, atingindo pacotes de até 5 MB, o que permitiu observar o comportamento das tecnologias sob condições críticas de uso industrial. No modelo REST, o processo de coleta de dados foi estruturado em quatro estágios evolutivos. O primeiro consistiu no uso básico do Axios com polling fixo de um segundo, sem qualquer mecanismo de cache ou tratamento de erros sofisticado. O segundo estágio introduziu o React Query com configurações padrão, visando observar o impacto do overhead natural da biblioteca na gestão de estados assíncronos.

O terceiro estágio de otimização do REST envolveu a implementação de polling adaptativo, onde o intervalo de consulta variava conforme a criticidade do dado e o estado de atividade da aba do navegador. Em momentos de falha detectada, aplicou-se a estratégia de exponential backoff com jitter, aumentando progressivamente o tempo entre as tentativas de reconexão para evitar sobrecargas no servidor (Brooker, 2015). Além disso, utilizou-se o cache HTTP com validação condicional através dos cabeçalhos ETag e Last-Modified, permitindo que o servidor respondesse com o código 304 sempre que não houvesse alterações no payload, economizando largura de banda (IETF, 2022). O quarto estágio focou na redução do payload, reconfigurando os endpoints para retornar apenas os campos estritamente necessários para a renderização dos componentes do dashboard.

Para a implementação do WebSocket, o fluxo operacional seguiu uma lógica de canal persistente. A configuração inicial utilizou STOMP.js e SockJS com envio fixo a cada um segundo. Posteriormente, aplicaram-se melhorias de resiliência, como o mecanismo de heartbeat, ou ping-pong, configurado para circular mensagens de verificação a cada 10 segundos, garantindo a manutenção da conexão ativa e a liberação de recursos ociosos (Fette e Melnikov, 2011). Para lidar com grandes volumes de dados, adotou-se a extensão permessage-deflate para compressão de mensagens JSON e, em cenários específicos, a serialização binária com MessagePack, reduzindo drasticamente o tempo de processamento e o tamanho dos pacotes transmitidos (Kainu, 2022).

A gestão da interface no frontend também foi detalhada para evitar vazamentos de memória e acúmulo de ouvintes de eventos. Implementou-se a Page Visibility API para detectar quando o dashboard estava em segundo plano, suspendendo temporariamente as atualizações e retomando-as automaticamente via resubscribeAll assim que a aba voltava ao estado visível (W3C, 2018). Essa abordagem garantiu a continuidade do fluxo de dados sem desperdício de processamento. Todo o processo de análise de dados foi estruturado para confrontar os resultados obtidos em cada estágio, permitindo uma discussão profunda sobre os limites de escalabilidade de cada protocolo frente ao aumento progressivo do volume de informações processadas.

Os resultados obtidos revelam distinções significativas entre as abordagens tecnológicas. No estágio inicial do modelo REST, utilizando Axios com polling fixo de um segundo, observou-se uma sobrecarga considerável, resultando em um score de desempenho de aproximadamente 60 no Google Lighthouse. O Total Blocking Time registrou 300 ms, evidenciando que a frequência de requisições e a ausência de cache forçavam o navegador a processar o payload completo repetidamente, elevando o custo de CPU. Surpreendentemente, a migração para o React Query sem ajustes finos reduziu o score para 41, com o Total Blocking Time subindo para 500 ms. Esse fenômeno é atribuído ao overhead de observadores e à gestão agressiva de cache da biblioteca, que, sem configuração adequada, gerou um consumo de recursos superior ao modelo simplificado.

Entretanto, após a aplicação das técnicas de otimização total no modelo REST, incluindo o polling adaptativo e o payload enxuto, o score de desempenho saltou para 98, com o Total Blocking Time reduzido para 100 ms. O First Contentful Paint fixou-se em 0,4 s e o Largest Contentful Paint em 0,8 s. Esses dados demonstram que o REST, quando devidamente configurado, é capaz de oferecer uma experiência de alta qualidade em condições de carga controlada. Contudo, a fragilidade desse modelo manifestou-se ao ampliar a carga. Sob uma carga duas vezes maior, o score caiu para 83 e, ao quadruplicar o volume de dados, o score atingiu 71, com o Total Blocking Time elevando-se para 660 ms. Esse comportamento confirma que a natureza do polling, que exige múltiplas requisições simultâneas, cria gargalos de escalabilidade tanto na rede quanto no processamento do cliente.

Em contrapartida, o modelo WebSocket apresentou um desempenho superior desde a sua implementação básica, atingindo um score de 91 mesmo sem otimizações avançadas. A latência inicial foi de aproximadamente 150 ms, superando a percepção de imediatismo do modelo REST. Com a aplicação das estratégias de resiliência e compressão, o protocolo atingiu um score de 99, com métricas de First Contentful Paint de 0,4 s e Total Blocking Time de apenas 100 ms. O diferencial mais expressivo do WebSocket foi observado nos testes de carga ampliada. Enquanto o REST sofria degradação acentuada, o WebSocket manteve a estabilidade, registrando um score de 94 sob carga duplicada e 86 sob carga quadruplicada. O Total Blocking Time manteve-se controlado em 300 ms mesmo no cenário mais severo, o que representa menos da metade do tempo registrado pelo modelo REST otimizado.

A discussão desses resultados aponta que a superioridade do WebSocket em cenários de alta demanda decorre de sua arquitetura de canal persistente e bidirecional. Ao contrário do REST, que exige o envio de cabeçalhos HTTP completos em cada requisição, o WebSocket reduz o overhead de comunicação após o handshake inicial. A capacidade de enviar dados apenas quando há atualizações reais na linha de produção minimiza o tráfego desnecessário, o que é crucial em redes industriais que podem estar congestionadas por outros sistemas de automação. A implementação da serialização binária com MessagePack mostrou-se um fator determinante, pois reduziu o tamanho das mensagens e acelerou a desserialização no frontend, permitindo que o ReactJS processasse as atualizações de estado de forma mais fluida (Kainu, 2022).

A análise também destaca a importância de práticas de resiliência para o sucesso do WebSocket. A fragilidade observada em testes preliminares, onde quedas de conexão deixavam o dashboard desatualizado, foi mitigada com o uso de exponential backoff e jitter. Essa técnica evita o fenômeno conhecido como tempestade de reconexão, onde múltiplos clientes tentam acessar o servidor simultaneamente após uma instabilidade de rede, o que poderia causar uma negação de serviço acidental (Brooker, 2015). Além disso, a integração com a Page Visibility API provou ser uma estratégia eficaz para a economia de recursos, alinhando o comportamento da aplicação com as necessidades reais do operador, que nem sempre mantém o foco visual constante na interface (W3C, 2018).

A comparação final entre as tecnologias indica que, embora o REST possa ser uma opção viável para aplicações de menor escala ou onde a frequência de atualização não seja crítica, ele exige um esforço de configuração significativamente maior para atingir níveis aceitáveis de performance sob carga. O uso de ferramentas como o React Query é essencial nesse contexto, pois facilita a implementação de cache e a deduplicação de requisições, estabilizando o comportamento do dashboard (Garg, 2025). No entanto, para sistemas de missão crítica que operam em tempo real, o WebSocket sobressai-se como a escolha técnica mais robusta, garantindo maior consistência e uma responsividade que atende aos requisitos rigorosos da monitorização industrial moderna.

As implicações práticas deste estudo sugerem que a escolha do protocolo não deve ser feita de forma isolada, mas sim integrada a uma estratégia de otimização que considere todas as camadas da aplicação. A redução do payload e a compressão de mensagens, como a extensão permessage-deflate, são fundamentais para minimizar o tempo de entrega e preservar a semântica da aplicação (IETF, 2015). No frontend, a gestão eficiente de assinaturas e ouvintes de eventos é vital para prevenir o acúmulo de processos que degradam a performance do ReactJS ao longo do tempo (Freeman, 2019). A combinação dessas técnicas permite que dashboards industriais operem com precisão milimétrica, transformando dados brutos em inteligência operacional sem os atrasos que historicamente limitavam a eficácia dos sistemas de suporte à decisão.

Limitações deste estudo incluem o foco em um ambiente de hardware específico e a utilização de dados sintéticos, embora estes tenham sido modelados para refletir fielmente a realidade fabril. Pesquisas futuras podem explorar cenários híbridos, onde o REST é utilizado para a carga inicial de dados históricos e o WebSocket assume a transmissão de atualizações incrementais, buscando o equilíbrio ideal entre simplicidade de implementação e performance extrema. Além disso, a investigação do impacto de arquiteturas distribuídas e do uso de múltiplos usuários simultâneos sobre a carga do servidor WebSocket pode fornecer insights valiosos para a escalabilidade horizontal dessas soluções em grandes parques industriais.

Conclui-se que o objetivo foi atingido ao demonstrar que, embora o modelo REST otimizado com técnicas de cache e polling adaptativo consiga entregar resultados satisfatórios em cenários de carga moderada, o protocolo WebSocket apresenta uma superioridade estrutural incontestável para aplicações em tempo real, mantendo a estabilidade e a baixa latência mesmo sob condições de estresse severo. A análise evidenciou que a simples adoção de uma tecnologia não garante a performance ideal, sendo a aplicação rigorosa de boas práticas de configuração, como a gestão de resiliência, a compressão de dados e a sincronização com o estado de visibilidade do navegador, o fator determinante para assegurar uma experiência de uso fluida e confiável em dashboards industriais desenvolvidos com ReactJS.

Referências Bibliográficas:

ALARCÓN, C.; VÁSQUEZ, F. Herramientas de visualización para la toma de decisiones en entornos industriales. Educación, Productividad y Tecnología, v. 1, n. 2, p. 56–70, 2021. Disponível em: https://revistas.uss.edu.pe/index.php/EPT/article/view/2863. Acesso em: 12 set. 2025.

BROOKER, Marc. Exponential backoff and jitter. AWS Architecture Blog, 2015. Disponível em: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/. Acesso em: 30 set. 2025.

FETTE, I.; MELNIKOV, A. The WebSocket Protocol. IETF RFC 6455, dez. 2011. Disponível em: https://tools.ietf.org/html/rfc6455. Acesso em: 16 set. 2025.

FREEMAN, A. Pro React 16. Berkeley, CA: Apress, 2019. Disponível em: https://www.apress.com/us/pro-react-16/16607668. Acesso em: 19 set. 2025.

GARG, T. React Query: Revolutionizing Data Fetching and Modernizing User Interfaces. TechRxiv, 2025. Disponível em: https://doi.org/10.36227/techrxiv.175000818.80756952. Acesso em: 30 set. 2025.

HYSENI, A.; SHKURTI, L.; KABASHI, F.; SOFIU, V. Development and Evaluation of a Real-Time Communication Web Application Using WebSocket’s, React, Node.js, and MongoDB. In: UBT INTERNATIONAL CONFERENCE, 2023, Prishtina. Prishtina: UBT Knowledge Center, 2023. Disponível em: https://knowledgecenter.ubt-uni.net/conference/IC/CS/29. Acesso em: 30 set. 2025.

INTERNET ENGINEERING TASK FORCE (IETF). Compression Extensions for WebSocket. RFC 7692, 2015. Disponível em: https://www.rfc-editor.org/rfc/rfc7692. Acesso em: 30 set. 2025.

INTERNET ENGINEERING TASK FORCE (IETF). HTTP Caching. RFC 9111, 2022. Disponível em: https://www.rfc-editor.org/rfc/rfc9111. Acesso em: 30 set. 2025.

KAINU, I. Optimization in React.js: Methods, Tools, and Techniques to Improve Performance of Modern Web Applications. Bachelor’s Thesis, Tampere University, 2022. Disponível em: https://trepo.tuni.fi/bitstream/handle/10024/140258/KainuIida.pdf. Acesso em: 15 set. 2025.

PAUTASSO, C.; WILDE, E. RESTful Web Services: Principles, Patterns, and Emerging Technologies. IEEE Internet Computing, v. 18, n. 6, p. 76–81, 2014. Disponível em: https://dl.acm.org/doi/10.1145/1772690.1772929. Acesso em: 16 set. 2025.

SOARES, J. C. A. Painéis de controle e inteligência de negócios em tempo real: um estudo aplicado. 2023. Dissertação (Mestrado em Engenharia Informática) – Universidade de Coimbra, Coimbra, 2023. Disponível em: https://eg-fr.uc.pt/handle/10316/107830. Acesso em: 15 set. 2025.

SOUTH AMERICAN DEVELOPMENT SOCIETY JOURNAL. Monitoramento em tempo real do índice OEE: estudo de caso num processo de apoio à tomada de decisão. v. 4, Esp01, p. 223–243, 2018. DOI: https://doi.org/10.24325/issn.2446-5763.vespi1p223-243. Acesso em: 16 set. 2025.

WORLD WIDE WEB CONSORTIUM (W3C). Page Visibility (Second Edition). W3C Recommendation, 2018. Disponível em: https://www.w3.org/TR/page-visibility-2/. Acesso em: 30 set. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy