Devo adotar interface web embarcada?

Nas últimas décadas vivenciamos as mais variadas formas de se comunicar com a máquina, e teorizamos até mesmo o que está por vir. Sem entrar a fundo no vasto campo da Interface Homem-Máquina (IHM), vamos lembrar de alguns fatos: gerações mais antigas usaram um telefone de disco; um seleto grupo viveu com beeper/pocket bell/pagers; criamos tecnologia para pessoas com Esclerose Lateral Amiotrófica pudessem se comunicar, como no caso de Stephen Hawking; e agora estamos discutindo como seria ter eletrodos implantados no cérebro para ouvir as nossas músicas favoritas.

Pois bem, o leitor talvez não esteja nem um pouco preocupado com o último caso, pois trabalha agora na empresa X que faz um produto Y. Depois da última entrega com sucesso, o seu chefe pediu mais um feature para o produto, e isso, não importa como você pense, envolve colocar mais um botão que não estava planejado no início. Talvez mais um LED aqui. Talvez mais algumas páginas no manual explicando como o novo feature funciona ali. Talvez um (re)treinamento para os técnicos entenderem o que é aquilo que você implementou.

A intenção deste artigo não é discutir se é correto ou não colocar um botão, ou LED, mas abrir mais o leque de possibilidades que é embarcar um servidor web (web server).

Como um servidor web funciona

Figura 1 – Funcionamento bem simplificado de uma interface web

Vamos supor que numa rede local estejam conectadas uma Raspberry Pi (server) e o seu computador (cliente). Você abre um navegador de preferência (Chrome, Firefox, Edge) e digita o endereço IP da Raspberry Pi. Ela atende a requisição e retorna uma página escrito em HTML, CSS e alguns scripts em JavaScript. A partir da interface que o cliente tem em mãos, ele faz uma nova requisição para Raspberry Pi, mas agora para acender um LED conectado à placa. O backend da Raspberry Pi vai interpretar essa requisição e executar o comando de acender o LED.

O frontend é mais certeiro em dizer que é composto de linguagens de marcação HTML e CSS, além dos scripts JavaScript. Já o backend tem diversas opções ou uma combinação entre elas. Algumas delas são:

  • Apache (web server)
  • Nginx (web server)
  • lighttpd (web server)
  • Node.js (runtime environment)
  • Django (web framework)
  • Flask (web framework)

A arquitetura pode se tornar um pouco mais complexa como o backend NodeJS interpretar a requisição e executar um script python e ainda registrar a ação num banco SQLite, e tudo isso estar rodando em um container Docker.

“Isso parece mais complicado do que o jeito usual que resolvo, porque iria implementar dessa maneira???”

Vantagens

1 – Menos hardware

Apesar de ser uma interface mais cheia de opções gráficas (por ser voltada para web) seria contra intuitivo falar que precisa de menos hardware. Porém, o sistema embarcado pode dispensar o uso de um display, e somente necessitar uma conexão com a rede. Em outras palavras, ao invés de instalar um display LCD no hardware embarcado, o device terá conexão WiFi ou ethernet, e utilizará o monitor do PC ou smartphone para visualizar o recurso gráfico. E caso haja restrição em utilizar WiFi ou ethernet, pode-se utilizar a porta USB do dispositivo para conectar um conversor USB-Ethernet.

Figura 2 – Exemplos de conversores/adaptadores USB-Ethernet disponíveis no mercado

O aproveitamento das telas do computador ou do smartphone existentes dispensa a instalação e a manutenção de um display próprio para o sistema embarcado. Há um esforço das aplicações de browser como Firefox, Chrome e Edge para padronizar o funcionamento do frontend, como também manter retrocompatibilidade com sistemas operacionais mais antigos. E em se tratando de smartphone, para se ter uma noção, Brasil é um dos cinco países com maior número de celulares. Considerar esses fatos pode levar a uma economia e corte de custos muito grande para o seu produto na prateleira.

2 – Utilização de uma interface consagrada pelo público

O cliente que vai comprar o seu produto espera interagir da mesma forma que se interage com os aplicativos de smartphone ou os sites que ele acessa no dia a dia.

O leitor pode contra-argumentar que nenhum dos dois são consolidados e que estão constantemente em desenvolvimento. Por outro lado, desenvolver um método próprio de interação com a máquina e que exija que o usuário leia um manual para operá-la pode afugentar a clientela.

E lembrando também que nesta década já teremos maiores de idade que passaram a primeira infância com um smartphone na mão.

3 – Distribuição do processamento

O frontend é processado no cliente que acessa o servidor. Então coisas como validação do input, navegação da página e animação é feita no computador/smartphone que está acessando o Raspberry Pi, por exemplo.

Desvantagens

1 – Curva de aprendizado

Se o desenvolvedor for iniciante neste nicho de programação, muito provavelmente não vai entender o funcionamento de muitas coisas, quebrar a cabeça com animações banais de CSS, e até praticar cargo cult programming. Depois do sucesso de uma primeira entrega, o pedido de features seguintes pode acabar virando uma bola de neve de débitos técnicos, especialmente caso faça parte de um time pequeno, ou seja um desenvolvedor solo.

2 – Hacking e Segurança

Por conta do ponto anterior exposto ou até mesmo por outras causas, o programador pode deixar os arquivos expostos demais, passar batido por técnicas de programação defensiva e até nunca sequer imaginar contramedidas para ataques de hacking.

Algumas dúvidas que podem surgir

Caso perca a minha anotação sobre o número de IP daquele dispositivo, como vou recuperar este número?

Ferramentas de software como Wireshark ou arp-scan podem ajudar a encontrar o número IP do equipamento na rede.

Em termos de hardware, outras soluções são vistos em produtos de mercado:

  • Ter duas portas ethernet, uma com IP fixo conhecido, e outra dinâmica;
  • Ter um botão que reseta o IP para um número conhecido.

Vou utilizar display embarcado de qualquer maneira, dá pra portar interface web nela?

Sim, e é conhecida como modo kioske. Dê uma olhada neste artigo.

Consigo implementar em microcontrolador?

Sim, porém a principal desvantagem em relação a um microprocessador é que o espaço é bem mais restrito.

Temos alguns artigos publicados no portal a respeito:

Outros artigos que implementam servidor web em sistemas Linux

Conclusão

Este artigo pode ser visto como artigo de opinião; alguns pontos colocados como vantagens e desvantagens são claramente discutíveis. A seção “Algumas dúvidas que podem surgir” e “Mais Links” (logo abaixo) contém links que podem servir de fonte de ideias para o leitor, e formar uma opinião diferente da minha aqui escrita.

A intenção foi focar sobre uma modalidade de interface que seja mais amigável para um usuário final que não seja um desenvolvedor. Caso seja um desenvolvedor ou um técnico que receberá treinamento pela empresa, o número de ferramentas para interfacear ou se comunicar com o dispositivo embarcado será maior (comunicação SSH, utilização de Postman, um hardware de interface desenvolvido pela própria empresa, etc.).

Saiba Mais

Sistema de votação em festas universitárias utilizando landing page

Wikipedia – Embedded HTTP server

embedded – 10 Things NOT to do when embedding a web server

Real Time Logic – Embedded Web Server Tutorials

JUNTE-SE HOJE À COMUNIDADE EMBARCADOS

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.
Home » Software » Devo adotar interface web embarcada?
Comentários:
Notificações
Notificar
guest
0 Comentários
Inline Feedbacks
View all comments
Talvez você goste:
Nenhum resultado encontrado.
Menu