Executando verificação de segurança...
2

frontend-react feat(frontend): add public 3D operations globe visualization

Cara, uma call que ouvi durante as enchentes do RS:

Uma aplicação X só deu certo e foi amplamente utilizada porque não tinha front-end

era html puro.

em um desastre a internet fica extremamente prejudicada, cada KB importa, o celular de uma pessoa em uma infraestrutura comprometida não vai conseguir baixar MBs de scripts de framework e muito menos um mapa 3d.

Se você quer que sua aplicação tenha chance: keep it simple

Carregando publicação patrocinada...
4

Fala Pilati, tranquilo?

Obriado pelo comentário! Você está totalmente correto!

Em cenários de desastre, a infraestrutura de rede geralmente está degradada ou parcialmente indisponível. Nessas condições, cada KB realmente importa, e aplicações pesadas dificilmente conseguem ser utilizadas por quem mais precisa.

O projeto mg_location (agora evoluindo para SOS-Location) está justamente sendo pensado para esse tipo de ambiente. A ideia não é depender apenas de uma interface moderna com mapas 3D ou frameworks pesados, mas sim construir uma arquitetura que funcione em múltiplos níveis de conectividade.

O plano de arquitetura é relativamente extenso e envolve alguns princípios importantes:

Modo de emergência extremamente leve (HTML simples, payload mínimo, funcionando mesmo em conexões muito limitadas).

Arquitetura offline-first, onde os dispositivos conseguem operar e registrar informações mesmo sem internet.

Sincronização oportunista (store-and-forward): dados são armazenados localmente e sincronizados quando qualquer tipo de conexão estiver disponível.

Comunicação local entre dispositivos usando tecnologias como Wi-Fi Direct ou Bluetooth para troca de dados curtos quando não há rede.

Gateways de campo (por exemplo um servidor portátil em um posto de comando) que podem concentrar informações localmente.

Backhaul opcional quando disponível, como Starlink ou outras formas de conectividade, para sincronizar com o sistema central.

Tráfego de dados extremamente compacto, priorizando mensagens curtas e estruturadas em vez de payloads grandes.

Ou seja, a ideia é que o sistema não dependa de uma única infraestrutura e consiga operar desde um cenário com rede mínima até ambientes com conectividade mais robusta.

O objetivo do projeto é justamente construir uma plataforma que continue útil mesmo quando a internet não está funcionando bem, que é exatamente quando ela é mais necessária.

Seu comentário é muito válido e está totalmente alinhado com a direção arquitetural que estamos planejando para o sistema.