Electron: As partes ruins – Agatetepê
Electron: As partes ruins
A maioria das linguagens de programação e frameworks de plataformas cruzadas contém partes boas e ruins. O elétron provavelmente tem mais do que sua parcela do bem – mas também esconde alguns segredos escuros sob sua fachada brilhante.
Embora a primeira impressão de Electron possa ser que ele resolva todos os problemas relacionados ao desenvolvimento de plataforma cruzada, a realidade é que muitas coisas não funcionarão fora da caixa e provavelmente não podem. Demorou bastante tempo para entender isso, e demorou ainda mais tempo até ter todas as soluções DIY no lugar para fornecer aos usuários coisas como instaladores corretos, atualizações, um mecanismo de feedback.
Esta lista de recursos na página eletrônica está estabelecendo altas expectativas
Eu sou um grande fã do Electron e pensei que a lista a seguir poderia ser muito útil para as pessoas que são novas no tópico. Mas os gerentes de projetos que estão avaliando diferentes pilhas e querem evitar "surpresas" também devem se beneficiar. A lista apresenta coisas que não são completamente claras no início. Coisas em que vale a pena gastar algum tempo extra na avaliação antes que uma decisão e um compromisso de longo prazo sejam feitos.
Uma vez que a codificação acabou e o planejamento de lançamento começa, a primeira decisão difícil está aguardando. Pode-se usar o instalador e o mecanismo de atualização conforme descrito na documentação eletrônica ou usar o instalador e o mecanismo de atualização que uma das melhores ferramentas do construtor (construtor de eletrônicos) recomenda.
A documentação oficial do Electron sugere o instalador do Squirrel (Windows e Mac) e o autoUpdater incorporado. Está disponível um servidor de lançamento de código aberto ("Nuts") que lida com o gerenciamento do lado do servidor de atualizações e lançamentos.
A outra opção é o próprio mecanismo de atualização do electron-builder "electron-updater". Baseia-se no instalador NSIS estabelecido (Windows) e em pacotes Mac simples. O construtor de eletrônicos usa essa abordagem como a configuração padrão para todos os instaladores gerados.
"Simultaneamente, mudar para NSIS por padrão parece ser um movimento muito drástico, considerando o projeto Eletron ainda recomenda Squirrel para Windows".
O projeto de construção de elétrons e elétrons discorda muito sobre qual solução é melhor. Isso leva a uma situação complicada em que os desenvolvedores devem decidir entre uma solução oficial (que muitos consideram complicada e não suficientemente flexível) e uma ferramenta simples e poderosa que possui suporte de ferramentas embutido. Pessoalmente, acho que o construtor de elétrons é uma benção se você realmente planeja fornecer instalações de seu software a milhões de pessoas ao redor do mundo e você não sabe por onde começar. Pode economizar semanas, senão meses de desenvolvimento, e considero que isso é uma parte essencial do ecossistema.
Aqui está uma lista de profissionais dos documentos electron-builder / electron-updater que devem ser considerados antes que uma solução seja escolhida sobre a outra:
Não requer um servidor de lançamento dedicado.
Validação de assinatura de código não apenas no macos, mas também no Windows.
O construtor de eletrônicos produz e publica todos os arquivos e artefatos de metadados necessários.
Baixe o progresso suportado em todas as plataformas, incluindo o MacOS.
Implementações implementadas em todas as plataformas, incluindo o MacOS.
Na verdade, o autoUpdater incorporado é usado dentro do macos.
Provedores diferentes suportados fora da caixa (GitHub, Bintray, Amazon S3, servidor HTTP (s) genérico (s)).
Você precisa apenas de 2 linhas de código para fazê-lo funcionar.
Integração contínua (CI) e compilações de plataforma múltipla
O elétron não deve ser confundido com uma "máquina virtual Java pré instalada". Você terá que fazer (construir, assinar, distribuir) sua plataforma cruzada de aplicativos. Não será plataforma cruzada "automaticamente".
Da documentação do construtor eletrônico
Isso pode ser bastante confuso e chocante, mas as construções multi-plataforma baratas e fáceis são um mito. É quase irônico com que frequência encontrar-se-á aplicações de "plataforma cruzada" que são "apenas para Mac" ou "apenas para Windows". A razão não é que seja complicado escrever código para múltiplas plataformas (o Electron lida com ele de forma surpreendente e a documentação é clara). A razão é simplesmente que muitos desenvolvedores não têm o grande orçamento ou acesso a outro hardware para testar e construir. Pior ainda: se você planeja ser um "desenvolvedor legítimo", seu aplicativo precisa ser assinado e pode ter uma ou mais dependências nativas.
A solução recomendada nesses casos é obter contas para diferentes provedores de CI: um para Mac (e Linux) e um para o Windows. Por quê? Como a Apple proíbe oficialmente o uso de seus sistemas operacionais
em máquinas virtuais em sistemas que não sejam OS X
em hardware não Apple
O resultado é que, se seu aplicativo estiver fechado, custará duas vezes mais para criar dois sistemas operacionais. E se o dinheiro e um sistema de compilação complexo não são e emitir, você ainda tem o problema de que o aplicativo só será testado e construído em vários sistemas. Neste momento, não pode ser enviado ainda. Assinar seu aplicativo remotamente com um certificado de assinatura de código de Validação Estendida (EV), por exemplo, é praticamente impossível com todas as ferramentas de CI existentes, uma vez que seu certificado está vinculado a um token de hardware físico que não pode / não deve ser transferido.
O fato de que cada aplicação vem com sua própria versão do Chromium (o 20 milhões de LOC, ~ 30MB [empacotado] tempo de execução da Web) é um dos aspectos mais criticados. Fato divertido: se você decidir hoje construir sua própria versão competitiva simplificada a partir do zero, provavelmente levaria 5.099 anos para construir . Alguns tentaram colocar o Electron em dieta e os críticos dizem que cria a sensação de instalar um sistema operacional completo em cima de um sistema operacional. Toda vez.
não é um problema
Embora muitas pessoas esperem que o Chromium reduza drasticamente o desempenho ou "consuma memória RAM preciosa", não experimentei nada disso na prática e não recebi comentários negativos de milhares de usuários de teste. Eu acho que não é um grande problema se você estiver acostumado a usar o navegador Chrome em segundo plano de qualquer forma. Mas eis o problema:
Não apenas as instalações agrupam o Chromium. Todas as atualizações também incluem Chromium, Node e todos os outros componentes eletrônicos, a menos que a atualização seja projetada como delta ou atualização diferencial.
Atualizações do Delta
Todo mundo que tenha experimentado uma atualização do Windows sabe que as atualizações sugam! Mas eles não precisam. As atualizações podem introduzir novas coisas legais, não precisam interromper o fluxo de trabalho e podem acontecer no fundo em vez de bloquear sua máquina por uma hora – eu estou olhando para você Microsoft. O ? é "atualizações delta". Em vez de desinstalar e reinstalar tudo, apenas as partes relevantes devem ser atualizadas de forma incremental.
O desafio: como trocar versões sem que o usuário perceba (inspirado no desenvolvimento de uma borda eletrônica )
Imagine o exemplo deste blog : uma classe de alunos está tentando um software e a atualização é de 70 MB de grande. 30 pessoas começam seus computadores e recebem uma atualização. Eles baixam a atualização simultaneamente, resultando em 2.1GB. Agora, compare isso com uma atualização delta, manipulada em segundo plano, que tem apenas 100KB de tamanho e reduz o total inicial de 2.1GB a 3MB. Isso diminuirá o tempo que cada aluno aguarda a atualização para se gravar no disco, para se registrar no sistema após o download; e leva carga de servidores, economiza banda, salva $$$, cria alunos e professores felizes.
O esquilo, em teoria, suporta atualizações delta. A partir da semana passada, construtor eletrônico com NSIS fornece uma solução beta para isso também. No entanto, eu não poderia chamar qualquer um deles para estar disponível fora da caixa.
Uma das aplicações em que estou trabalhando – Autobeat Player – usa seu próprio mecanismo de atualização "delta" que atualiza o aplicativo inteiro . A torção: toda a aplicação sem módulos e bibliotecas externos é de apenas ~ 750KB (!) Em tamanho. Sempre que menciono isso, as reações são inestimáveis. A maioria das pessoas não pode acreditar no tamanho reduzido considerando a riqueza e a complexidade da aplicação. Uma aplicação de desktop inteira que tem o tamanho de uma única imagem é como descreveria uma nova geração de aplicativos de desktop (Electron). E a maneira como implementamos atualizações no Autobeat é direta e nenhuma ciência do foguete.
Tudo o que pode ser considerado remotamente como estático não faz parte da imagem da aplicação : jQuery, Font Awesome, Bootstrap ou todas as outras bibliotecas frontend e qualquer um dos módulos do nó não fazem parte do próprio aplicativo .
Se alguém tira tudo o que não está mudando com freqüência, como essas bibliotecas, e apenas atualiza a parte da lógica do aplicativo – as coisas em que você está realmente trabalhando – uma queda de tamanho de 99,9% é absolutamente possível. No entanto, ele requer lógica de atualização personalizada. Não existe uma solução padrão disponível. O benefício: no caso do Autobeat, podemos atualizar o aplicativo como um todo, desde que as dependências externas não estejam mudando, o que raramente acontece. As atualizações levam entre 1-2 segundos e passam despercebidas. É como atualizar um site – depois de uma atualização, parece diferente. Não há necessidade de se preocupar que os deltas são mal calculados ou as peças não estão funcionando juntas como esperado. De vez em quando, adicionamos mais dependências e precisamos fazer uma atualização "completa" de 31MB. Mas estamos fazendo uma aposta de longo prazo aqui, assumindo que esses intervalos ficam cada vez mais longos, enquanto nossos ciclos de lançamento regulares podem ser tão curtos quanto um par de horas. E todos os dias estamos aprendendo mais sobre como alavancar as coisas que funcionam para a Web e como trazê-las para o desktop para serem lançadas de forma mais eficiente.
A separação entre a lógica do aplicativo e as bibliotecas, conforme descrito acima, desbloqueia outra característica muito poderosa: ele potencialmente permite lançar um segundo aplicativo, que compartilha as mesmas bibliotecas principais existentes e não requer a instalação de outro pacote empacotado pelo Chromium ou a necessidade de assinar e distribuir um novo instalador. Ele cria um ambiente como um navegador superpropiado que suporta jQuery, Vue, Font Awesome, Polymer e todas as outras estruturas, bem como todos os módulos de nó relevantes fora da caixa e minimiza o tamanho do aplicativo. Pense nisso por um segundo.
Em testes recentes, nossa equipe lançou com sucesso outros "aplicativos instantâneos" (<1 MB) em uma forma distribuída e P2P em uma fração de segundo. Da mesma forma, iria iniciar aplicativos em uma TV alimentada com Chromecast, também é possível carregar remotamente aplicativos em outras máquinas. Quando percebi que acabamos de lançar um software de desktop totalmente caracterizado a partir de um servidor web em execução em um smartphone, sentiu-se parcialmente como criar a próxima geração de aplicativos descentralizados e em parte como a próxima geração de vírus.
Da mesma forma que os navegadores podem carregar qualquer site, o Eletron potencialmente pode carregar tantos aplicativos quanto quiser sem a necessidade de reinstalar o tempo de execução repetidamente. E quanto mais a linha entre a Web e a área de trabalho ficar borrada, mais desafios enfrentamos como usuários para proteger nossas máquinas e dados.
O elétron também pode carregar sites como qualquer outro navegador. Existem ferramentas iguais, como o decadente extremamente popular que envolve os sites existentes. Esses "sites-aplicativos nativos" podem potencialmente ativar a webcam ou o microfone, acessar o sistema de arquivos e criar, excluir, criptografar as coisas que desejarem ou enviá-las para os servidores – e na maioria das vezes isso se destina. Eventualmente, o servidor de hospedagem se torna o servidor de comando e controle de uma botnet gigantesca.
"Uma vez que você obtém seu primeiro milhão de usuários, seu atualizador automático é basicamente um botnet com um milhão de nós. Com grandes poderes vem grandes responsabilidades. "
O elétron oferece muitos mecanismos de proteção: o modelo sandbox pode ser ativado, a integração do nó pode ser desativada, scripts de pré-carga e webviews criam ambientes locais com diferentes permissões … No entanto, ele me diz que essas aplicações web de desktop evoluem e distribuem mais rápido que o nosso antigo modelos de segurança. Coisas como a assinatura do instalador e as autoridades confiáveis ​​estão em processo de tornar-se sem sentido em um mundo onde os sites podem ser executados como aplicativos de pleno direito fora de sua caixa de areia.
"Toda vez que você baixar o expresso, você prefere este tweet exato de Hot Pockets" – sátira por Jordan Scales
Recentemente, estava participando de uma conversa de uma inicialização bem financiada que verifica e analisa os módulos npm para vulnerabilidades para alertar os desenvolvedores antes de integrá-los. Quando perguntei se eles também considerariam a segurança do módulo npm em um contexto desktop, a resposta era que eles não examinaram isso e que não tem prioridade. Mas cada módulo que fazemos referência e instalamos na máquina de um usuário vem com suas próprias dependências e acabamos compartilhando a confiança e as permissões do usuário com os módulos que perdemos e, muitas vezes, nem sequer conhecemos. Num momento em que um único ataque cibernético, como o recente sistema de resgate WannaCry, pode ter um impacto financeiro de até US $ 4 bilhões , estamos enfrentando novos desafios. Isto é especialmente importante quando você lê sobre módulos populares que retweet anúncios de bolso quente em segundo plano sempre que são instalados.
Proteção de código
Da mesma forma que queremos proteger os usuários, talvez também queiramos proteger nossos próprios e o trabalho da nossa empresa. Os aplicativos eletrônicos geralmente são distribuídos em arquivos de contêineres. Para recuperar o código fonte simples de uma instalação e seu arquivo ASAR contido é tão simples como:
asar extract app.asar secret_source_code
Os arquivos não ficam ofuscados, criptografados ou protegidos por padrão, o que significa que alguém que quer temperar com um aplicativo pode receber a cópia de trabalho do repositório. Isso torna o Electron um ajuste muito pobre para soluções comerciais.
A declaração oficial do Electron lê assim :
A idéia é que qualquer tipo de proteção interna pode ser ignorada de qualquer maneira (o que é verdade) e simplesmente roubaria recursos de áreas mais importantes (o que é verdade).
Nossos produtos usam algumas técnicas de ofuscação e criptografia e definitivamente não são tão sensíveis como dizem os tokens Ethereum . Mas muitos lutam com a proteção, então aqui é um exemplo simples para alcançar a criptografia do código fonte durante a embalagem:
const crypto = require ('crypto')
var password = new Buffer ('my secret password');
função transformar (nome do arquivo) {
retornar crypto.createCipher ('aes-256-cbc', senha);
asar.createPackageWithOptions (src, dest, {transform: transform} ..)
A opção de transformação de Asar permite especificar um transformador de fluxo que é aplicado quando os arquivos são empacotados no contêiner asar. No entanto, em algum momento, você terá que descriptografar seus arquivos e é aí que fica realmente complicado. Além disso, se sua senha estática escorrer você não está ganhando nada. Existem outras opções como a criação de um instantâneo V8 ou para usar binários C ++ e pode-se definitivamente tornar sua "batalha" tanto quanto eles desejam. O principal takeaway aqui é que o Electron fornece perto de nenhuma proteção e cada minuto que você investir em segurança, espero, crie 5 minutos para um hacker.
Se você tem um aplicativo Electron você mesmo e gostou do artigo, gostaria de obter outra perspectiva, ou se você acha que algo está faltando, apresentado de maneira errada ou imprecisa, deixe um comentário, aplaude ou entre em contato.
Para manter este artigo "curto", estou pensando em compilar material adicional e mais detalhado. Tópicos adicionais podem ser relatórios de falhas, separação da lógica do processo principal e do processador, análise, distribuição do instalador, rastreamento de campanha e redefinição de usuários através de notificações. Se você estiver geralmente interessado em mais informações, avise-me:
Link para formulário: https://goo.gl/forms/cnXgxM8fmg60f4lX2
Bom guia de visão eletrônica: https://blog.dcpos.ch/how-to-make-your-electron-app-sexy
electron-builder: https://github.com/electron-userland/electron-builder
Atualização oficial docs: https://electron.atom.io/docs/api/auto-updater/
electron-updater: https://www.electron.build/auto-update
Esquilo para migração NSIS: https://github.com/electron-userland/electron-builder/issues/837
Construções multi plataforma: https://www.electron.build/multi-platform-build
suporte de atualização de delta eletrônico-construtor: https://github.com/electron-userland/electron-builder/issues/1523