Neste artigo, continuo a série de publicações nas quais quero falar sobre minha experiência na criação de uma extensão da Web para navegadores. Eu já tinha experiência na criação de uma extensão da Web, instalada por cerca de 100.000 usuários do Chrome, que funcionavam de forma autônoma, mas nesta série de artigos eu decidi me aprofundar no processo de desenvolvimento da extensão da Web, integrando-a firmemente ao lado do servidor.



Parte 1 , Parte 3 , Parte 4

Escolhendo uma estrutura para o lado do servidor

No começo da minha ideia, eu estava pensando em como salvar os dados obtidos como resultado do script. A possibilidade de usar o locaStorage ou soluções semelhantes para um banco de dados do lado do cliente veio à mente. À medida que o planejamento do código avançava nesse caminho, descobriu-se que o download de arquivos e o armazenamento no computador do usuário não são uma boa ideia, pois o usuário estará vinculado a um computador.

Portanto, é necessário salvar scripts do usuário, dados obtidos como resultado da execução de scripts no lado do servidor. Os arquivos do usuário também devem ser carregados pelo lado do servidor. O usuário deve registrar, redefinir a senha etc. diretamente pela interface de extensão da Web, porque o registro em uma página separada não permitiria interação confortável com a extensão da Web.

Assim, foi escolhida a maneira de usar o XHR em conjunto com a API RESTful. Essa opção também permite o uso futuro do mesmo código para criar um sistema de entrega de dados em pipeline. Por exemplo, a obtenção de posições de recursos da Web nos resultados dos mecanismos de pesquisa pode ser agendada em um ciclo diário. Depois disso, um aplicativo de terceiros solicita dados obtidos como resultado do script usando a API e cria um gráfico mostrando a tendência da posição de mudar nos resultados da pesquisa.

Muitas estruturas em diferentes linguagens de programação possuem bibliotecas, módulos e pacotes para o rápido desenvolvimento de aplicativos de servidor RESTful. Há cerca de 12 anos, trabalho com várias estruturas baseadas em PHP e, nos últimos 3 anos, também trabalho com o Meteor.js. Essa estrutura é executada em cima do node.js, então eu a escolhi para a parte do servidor devido ao seu alto desempenho (em média 112 milissegundos por registro de uma linha de dados recebida do script) e um rico conjunto de pacotes prontos para a construção do aplicativo.

Como biblioteca RESTful, escolhi o pacote github.com/kahmali/meteor-restivus , que, entre outras coisas, precisava ser corrigido, pois não funcionava corretamente com autorização de gancho e proteção contra a técnica de adivinhação de senha infinita.

O Restivus possui boa funcionalidade para descrever a API RESTful e suporta o trabalho de maneira autorizada ou anônima. Token e userId são usados ​​como confirmação da autoridade para executar um método definido pelo usuário em um endereço RESTful. Esses parâmetros podem ser armazenados nas permissões da web localStorage e usados ​​ao chamar o XHR.

Para a zona administrativa, escolhi o pacote extensível e altamente configurável github.com/yogiben/meteor-admin , que me permitiu reduzir o tempo para criar muitas páginas do mesmo tipo para as necessidades da equipe de segurança.

Criando uma interface para extensões da Web

A interface desempenha um papel decisivo na seleção de um produto pelo usuário. Conveniência e minimalismo foram escolhidos como os principais critérios para a interface de extensão da web. Posteriormente, um lado estético foi adicionado para concluir toda a aplicação.

Semantic-ui foi escolhido como o framework css / html. Ao mesmo tempo, recusei pacotes npm adicionais e mecanismos de montagem como o webpack para minimizar dependências e o tamanho da extensão da web. O código é gravado da maneira mais transparente possível, usando apenas três bibliotecas js e arquivos de terceiros.

Para iniciar o processo, uma lista de páginas necessárias foi compilada. As páginas para trabalhar com uma conta de usuário foram agrupadas nessa lista.

1. Página de login
2. Página de registro
3. Página de redefinição de senha

Nesse momento, havia um problema de redefinição de senha de link único. Em um aplicativo normal, o usuário pode seguir o link, redefinir a senha e inserir o aplicativo. Uma extensão da Web pode "interceptar" links usando navigator.registerProtocolHandler e autorizar um usuário em uma extensão da Web, mas nem todos os navegadores suportam isso. Portanto, foi decidido redefinir a senha pelo link e, em seguida, o usuário pode inserir a extensão da web usando a nova senha.

Abaixo está um formulário para registrar um novo usuário na extensão da web.


Aqui você pode ver elementos para marketing social, como o código Convidar e links para distribuição nas redes sociais ao lado do elemento para enviar uma pergunta ao serviço de suporte.

Após o registro ou a autorização, o usuário pode editar seu perfil diretamente na extensão da web. Isso melhora qualitativamente a solução atual, pois elimina a necessidade de trabalhar com um site separado. O usuário pode executar todas as ações em um só lugar.


Todas as telas são divididas em guias, o que permite mover-se rapidamente entre as telas e desempenhar o papel de um tipo de menu. Em alguns casos, para uma representação mais visual, os elementos são minimizados para a iteração atual. Por exemplo, as assinaturas de botão são colocadas nos próprios botões, embora no futuro seja planejado substituir a lista vertical de botões por uma horizontal e remover as assinaturas nas dicas de ferramentas. Isso é feito para maximizar a apresentação de extensões da web para novos usuários. É assim que é feita a tela principal com uma lista de scripts para a iteração atual.


Cada script de usuário deve ser criado por alguém. Como mencionado anteriormente na extensão da web, pode haver scripts públicos e privados. Para adicionar scripts, use o seguinte formulário simples.


Além disso, o usuário pode definir um sinal de publicidade de script, o que permitirá que outros usuários usem a experiência da comunidade de extensões da web.

Scripts públicos têm várias limitações. Por exemplo, eles não podem ser usados ​​para inicialização em uma página, no planejador de tarefas e possuem teclas de atalho. Além disso, cada script público tem a capacidade de "editar", durante o qual o usuário pode remover o sinal de publicidade e salvá-lo em um estado privado como seu próprio script. Essas etapas adicionais são necessárias para proteger contra desenvolvedores sem escrúpulos. Ao "editar" um script público, o usuário deverá revisar o código e decidir sobre seu uso para suas necessidades.

O download de arquivos na extensão da web é implementado através da leitura do conteúdo do arquivo no buffer, codificação e envio posterior pelo canal XHR para o servidor. No servidor POST, a solicitação é processada e o arquivo é enviado para o armazenamento em nuvem. Nos scripts, os usuários podem ler os arquivos baixados através do GC.loadFile ('filename.ext'); , uma função da biblioteca interna sobre a qual um artigo separado será escrito.


Cada script pode gravar dados de cálculos chamando a função da biblioteca interna. Cada chamada gravará uma linha em uma célula com o mesmo nome para todas as linhas. Dessa forma, você pode gravar arquivos CSV. A tela abaixo mostra a interface para trabalhar com dados de saída. O usuário pode baixar os dados diretamente da extensão da web, enviar o arquivo gerado para o email, obter um link para a API para uso em aplicativos de terceiros ou excluir os dados.


Todas as ações que alteram o estado do script, como a ação de exclusão, requerem confirmação. A extensão da web tem uma restrição ao uso de janelas pop-up ou de confirmação, uma vez que ela própria possui uma interface sendo executada em pop-up. Portanto, o mecanismo de entrada da palavra de confirmação é usado.


No próximo artigo, falarei sobre as "armadilhas na implementação da interação de extensões da Web e do lado do servidor" .