O principal segredo para o desenvolvimento de boas aplicações de elétrons

Alguns odeiam ferozmente aplicativos de elétrons . O fato de o aplicativo incluir o navegador Chromium parece, para dizer o mínimo, estranho. Esse sentimento é aprimorado durante o trabalho com esses aplicativos. Eles consomem muita memória, carregam lentamente e não apresentam uma taxa de reação particularmente alta às interações do usuário. Não é fácil desenvolver um bom aplicativo da web. Por que as tecnologias da Web são arrastadas para o ambiente de desktop? Afinal, há um sentimento de que nesse ambiente eles criam um monte de problemas?

O autor do material, cuja tradução publicamos hoje, afirma que não desempenhará o papel de defensor da Electron, embora tudo fale do sucesso dessa plataforma. É verdade que ninguém vai descontar os excessos inerentes às aplicações de elétrons. É possível, durante o desenvolvimento de tais aplicações, matar dois coelhos com uma cajadada em um tiro?


Alguns dos problemas da Electron (arquivos grandes, carregamento lento) são um legado das tecnologias nas quais esta plataforma se baseia. Eles precisam ser abordados em um nível baixo. Problemas mais sérios (consumo de memória, lentidão das interfaces) podem ser resolvidos no nível em que as aplicações Electron estão sendo desenvolvidas. No entanto, resolver esses problemas não é fácil. E se houver um segredo, sabendo que você pode, no modo automático, minimizar essas deficiências?

Se você gosta de ler o código do programa, pode procurar imediatamente neste repositório. Aqui está o projeto que será considerado neste material.

A essência do segredo

O segredo para desenvolver aplicativos de elétrons de alta qualidade é realizar a maior parte dos cálculos no sistema local, nos processos em segundo plano. Quanto menos você confiar nos serviços em nuvem e quanto mais você trabalhar em processos em segundo plano, mais poderá experimentar os seguintes efeitos positivos:

• Carregamento instantâneo de dados. Os usuários do aplicativo nunca terão que esperar o download dos dados pela rede. Os dados são baixados do armazenamento local. Isso imediatamente dá ao aplicativo um aumento tangível no desempenho.
• Baixos requisitos de armazenamento em cache. O aplicativo cliente não precisa se preocupar particularmente com o cache. Isso ocorre porque todos os dados de que ele precisa estão disponíveis localmente. Para que um aplicativo Web atinja um nível decente de desempenho, ele geralmente precisa carregar uma quantidade impressionante de dados em seu estado local. Esse é um dos motivos do consumo de memória muito alto dos aplicativos Electron.

Aqui não estou falando de outras vantagens do armazenamento local de dados, por exemplo, sobre a possibilidade de trabalhar sem conectar-se a uma rede.

Veja a quantidade de memória que meu aplicativo Electron consome - o gerente de finanças pessoais da Actual . Este programa armazena todos os seus dados localmente. A sincronização de dados entre diferentes dispositivos é um recurso opcional, não afeta a funcionalidade principal. Suponho que, como esse aplicativo foi projetado para funcionar com grandes quantidades de dados, seus números de consumo de memória falem por si mesmos.


Consumo real de memória

Um aplicativo que não executa nenhuma ação ativa ocupa um total de 239,1 MB de memória. Esse indicador pode ser mais, depende do que exatamente está acontecendo no aplicativo, mas é possível usar apenas o número especificado como base. Isso não é perfeito, mas não é tão ruim. Pelo menos - melhor que os 1371 MB de memória necessários no meu computador Slack. Devo dizer que o Slack é um exemplo atípico de uma aplicação eletrônica, caracterizada por problemas específicos. Houve alguma sensação em torno de Electron devido ao Slack. Outros aplicativos, como Notion ou Airtable, consomem aproximadamente 400-600 MB de memória. E isso significa que meu aplicativo ganha bem a esse respeito e eles têm.

Devo dizer que o número de 239,1 MB foi obtido por mim antes de qualquer otimização. Pretendo reescrever algumas das partes extremamente importantes e com muita memória do aplicativo no Rust. Isso deve reduzir significativamente os requisitos de memória do aplicativo.

Um servidor em segundo plano pode otimizar seu próprio consumo de memória carregando apenas na memória os dados necessários em um determinado momento. É melhor usar algo como SQLite para armazenamento de dados. Esse DBMS já está seriamente otimizado para resolver esses problemas (sério - basta usar o SQLite). Além disso, deve-se notar que mover vários cálculos para processos em segundo plano permite que a interface do usuário do aplicativo responda às influências do usuário o mais rápido possível.

Descobriu-se que o uso de um servidor em segundo plano em um aplicativo Electron oferece ao desenvolvedor oportunidades interessantes. Na próxima seção, falaremos sobre todas as coisas incríveis que podem ser feitas com seu uso.

Mesmo se seu aplicativo estiver seriamente vinculado aos dados da nuvem, você poderá precisar de um processo em segundo plano se pretender trabalhar com a API do Node.js. A interação com essas APIs é possível apenas a partir de processos em segundo plano. De fato, qualquer que seja a sua aplicação Electron, acredito que conhecer o projeto que examinaremos agora pode lhe dar algumas idéias úteis.

Aplicativo de exemplo de elétron com servidor

Criei o aplicativo elétron com exemplo de servidor para mostrar tudo o que precisa ser configurado para desenvolver aplicativos Electron verdadeiramente locais usando seu exemplo. Fiz isso em um esforço para cativar os programadores criando projetos semelhantes. Eu gostaria de conhecer um projeto semelhante no momento em que estava começando a trabalhar com a Electron.

Informações técnicas sobre o aplicativo podem ser encontradas no README - README . Aqui está uma visão geral do projeto:

• Ele cria o processo Node.js usual, usado para executar o código do servidor em segundo plano.
• Nele, usando o node-ipc , é criado um canal IPC, projetado para organizar a interação direta entre o back-end e a interface do usuário do aplicativo.
• Se o projeto for iniciado no modo de desenvolvimento, o servidor não iniciará como um processo em segundo plano. Você pode interagir com ele através de uma janela separada do navegador. Isso é para fins de depuração.

Agora vamos desacelerar um pouco e dar uma olhada no último item desta lista. No modo de desenvolvimento, você pode interagir com o servidor através de uma janela separada do navegador?


Partes de cliente e servidor do aplicativo

É sim. Depois de aprender como iniciar processos em segundo plano, percebi, em primeiro lugar, que tenho à minha disposição as ferramentas do desenvolvedor do Chromium. E segundo: percebi que, para fins de depuração, posso usá-los para depurar o código Node.js. Como resultado, estou falando sobre o fato de que você pode interagir com o Node.js por meio de um navegador. Isso permite que você use o rico kit de ferramentas para desenvolvedores de navegador baseado em Chromium para depurar o código do servidor.

Agora, vamos ver todas as coisas interessantes que podemos fazer graças à aplicação do esquema de inicialização do aplicativo acima.

Usando console

server-ipc.js comandos para registrar solicitações e respostas no arquivo server-ipc.js . Eu posso explorá-los usando o console do navegador.


Depurando aplicativos Node.js no console do navegador

Execução de código passo a passo

Ao depurar o lado do servidor do aplicativo usando um navegador, você pode usar a execução de código passo a passo. Isso não quer dizer que seja algo absolutamente fantástico. Mas é muito conveniente que esse recurso esteja sempre disponível e não exija o uso de programas adicionais.


Execução de código passo a passo

Criação de perfil

Talvez esta seja minha ferramenta favorita. Essa é uma ferramenta padrão brilhante para pesquisar o desempenho do código, que permite o perfil do lado do servidor do aplicativo.


Pesquisa de desempenho do código do servidor

Usando as ferramentas do desenvolvedor do navegador, você pode até explorar o que acontece quando o processo em segundo plano é iniciado (essa é provavelmente a parte mais difícil de iniciar o aplicativo).

Para fazer isso, basta iniciar o processo de gravação de indicadores e recarregar a janela. A reinicialização fará com que o servidor reinicie. Isso nos leva ao próximo passo.

Reiniciando o servidor usando a combinação de teclas Cmd + R ou Ctrl + R

Outra das opções para depurar o código do servidor em um navegador é que, como a depuração do servidor é realizada em uma janela do navegador, basta recarregar o conteúdo da janela para que o servidor seja reiniciado! Basta usar a combinação de teclas Cmd+R (ou, para Windows, Ctrl+R ), e à sua disposição estão as últimas alterações feitas no código do servidor. Nesse caso, os dados do front-end são salvos. Isso significa que você pode continuar trabalhando com a parte do cliente do aplicativo, mas, após reiniciar o servidor, a parte do cliente já funcionará com a nova versão do código do servidor. Isso lembra algo como uma troca de código "quente" em um servidor em execução.

A figura a seguir mostra como, alterando o código do servidor, recarreguei a página pressionando Cmd+R Depois disso, continuei trabalhando com o cliente, que agora está interagindo com a nova versão do servidor.


Reinicialização do servidor

Pesquisando o Lado do Servidor em Execução do Aplicativo e o Código de Troca Quente

Normalmente, ao depurar o servidor, simplesmente adiciono o comando console.log() nos locais certos do código e o reinicio. Mas, às vezes, em casos especialmente difíceis, acontece que seria extremamente útil examinar o que está acontecendo em um servidor em execução, em vez de reiniciá-lo. É possível que não apenas “olhe” dentro do servidor, mas também mude algo nele para ver como isso afetará o problema.

No console, você pode usar o comando require Node.js. Isso significa que, com sua ajuda, você pode conectar quaisquer módulos do servidor e trabalhar com eles no console.

Suponha que precisamos trabalhar com o server-handler.js . Para fazer isso, basta executar o comando let handlers = require('./server-handlers') no console.

Vamos criar um sistema para armazenar o status do servidor. No nosso caso, esta será uma lista de todos os dados passados ​​para a função de make-factorial (o estado do servidor do aplicativo real será muito mais complicado):

 handlers._history = [] handlers['make-factorial'] = async ({ num }) => {  handlers._history.push(num) } 

Você pode handlers._history status do servidor no console conectando o módulo apropriado e examinando handlers._history . Se desejado, durante a execução do programa, podemos até substituir completamente a implementação do make-factorial !


Pesquisa de status do servidor

Sumário

Dê uma olhada no repositório electron-with-server-example para ler sobre os detalhes da implementação do projeto e ver o código do lado do servidor do aplicativo Electron.

Se você usa o Visual Studio Code, pode estar acostumado a uma integração de alta qualidade de ferramentas de desenvolvedor com o servidor Node.js. Com essa abordagem, você pode iniciar o servidor sozinho, separadamente do aplicativo Electron. Depois disso, você pode informar à Electron que você precisa se conectar ao processo de propriedade do VS Code. No entanto, prefiro usar as ferramentas de desenvolvimento de elétrons existentes.

Isso significa que o programador tem a oportunidade de usar qualquer ferramenta de edição de código de terceiros e, ao mesmo tempo, ter acesso total a todas as ferramentas de desenvolvedor de navegador.

Nos últimos anos, desenvolvi o aplicativo Actual e constantemente uso o que acabei de falar. E eu quero dizer que eu realmente gosto de tudo isso. Talvez o trabalho na parte Node.js desse aplicativo tenha se tornado a fonte da experiência de programação mais agradável que já experimentei.

Além disso, é muito importante que os princípios descritos acima nos ajudem a desenvolver aplicativos realmente locais. Já temos todas as tecnologias necessárias para isso. O principal é usá-los corretamente.

Caros leitores! Como você se sente com os aplicativos baseados em elétrons?