Criando nosso rastreador de sites: uma olhada na tecnologia da Weglot

Muitos usuários Weglot gostam de garantir que todos os URLs de seu website sejam traduzidos com precisão(após a primeira camada de tradução automática fornecida pelo Weglot). Para muitos, se você possui um website grande, traduzido em vários idiomas, isso pode consumir muito tempo.

Também percebemos, por meio do feedback de nossos usuários, que alguns deles estavam um pouco confusos ao iniciar seu primeiro projeto de tradução de websites. Muitas vezes, eles se perguntavam por que só conseguiam ver o URL da página inicial na lista de tradução e não o de todas as outras páginas, ou como gerar as traduções de seu conteúdo.

Portanto, sabíamos que havia espaço para melhorias nessa área. Poderíamos ajudar nossos usuários a embarcar com mais facilidade e gerenciar seus projetos com mais rapidez e eficiência, mas o único problema é que ainda não tínhamos uma solução.

Como você já deve ter adivinhado... isso levou ao lançamento do recurso Gerenciar URLs, que permite ao usuário verificar os URLs de seu site e gerar seu conteúdo traduzido a partir do Weglot Dashboard, de forma rápida e eficiente.

Recentemente, esse recurso foi transferido da Lista de traduções para a nova página de gerenciamento de traduções por URL, onde se tornou ainda mais flexível e avançado.

Golang para o resgate

No início de 2020, o confinamento devido à pandemia finalmente me deu a oportunidade de aprender a linguagem de programação Golang, que tive de adiar por falta de tempo.

Golang (ou Go, para abreviar) é uma linguagem criada pelo Google que está ganhando muita força nos últimos anos.

É uma linguagem de programação compilada estaticamente que foi projetada para ajudar os desenvolvedores a escrever códigos rápidos, robustos e simultâneos. Sua simplicidade permite escrever e manter programas grandes e complexos sem sacrificar o desempenho: Golang pode ser visto como o filho inesperado de Python e C: (bastante) fácil de escrever e rápido de executar.

Na minha opinião, a melhor maneira de aprender uma nova linguagem de programação (ou uma nova estrutura ou qualquer outra) é encontrar um bom projeto para colocar em prática o que você aprendeu. Não é a tarefa mais fácil: se os desenvolvedores estiverem lendo isto, eles sabem o quanto isso pode ser difícil. 

Um bom projeto paralelo deve atender a algumas especificações:

• O escopo deve ser grande o suficiente para que o desenvolvedor possa aprender o suficiente da tecnologia que está aprendendo enquanto constrói o programa: imprimir "Hello world" no console raramente é suficiente para obter uma compreensão de uma nova linguagem.
• O escopo não deve ser tão grande que o desenvolvedor provavelmente desistirá antes de concluir o projeto (todos nós já passamos por isso).
• Por último, mas não menos importante, deve ser divertido de fazer! Programar uma lista de tarefas pela 200ª vez não será muito divertido; é bem provável que você desista assim que pensar em como fazê-la funcionar. 
• Ponto de bônus: o ideal é que o projeto paralelo resolva um problema do mundo real, o que ajuda a manter o foco na tarefa.

Então, por que estou mencionando isso? Enquanto pensava no que poderia ser um ótimo projeto paralelo para começar a aprender Golang, ocorreu-me que um rastreador da Web poderia se encaixar perfeitamente na descrição acima e também poderia resolver alguns dos problemas que estávamos procurando corrigir para os usuários Weglot .

Vamos pensar um pouco: um rastreador da Web (geralmente chamado de "bot") é, em sua forma mais simples, um programa criado para visitar um site e extrair informações.

Um caso de uso típico de um rastreador da Web poderia ser descobrir e visitar todas as páginas de um site e, em seguida, gerar um mapa do site. Ou indexar seu conteúdo, como os bots do Google, por exemplo.

No nosso caso, precisávamos de algo que nossos usuários pudessem usar para analisar seus sites e importar de volta todos os URLs do site. 

Também estávamos procurando uma nova maneira de gerar traduções. Observação para quem não está familiarizado com o Weglot... "gerar traduções" significa que seus URLs (e o conteúdo dentro deles) aparecem na lista de traduções Weglot , permitindo que você faça edições manuais nas traduções.

Nesse ponto, os usuários tinham de visitar o site em um idioma traduzido para gerá-los. Isso funciona muito bem quando seu site tem apenas algumas páginas e você não tem muitos idiomas traduzidos, mas pode rapidamente se tornar uma tarefa árdua se você tiver um site muito grande com milhares de páginas.

A ideia de usar um rastreador da Web para automatizar essa tarefa rapidamente começou a parecer uma solução ideal e seria um caso de uso perfeito para os recursos de programação simultânea do Golang!

Assim, em janeiro de 2020, comecei a criar um protótipo de um rastreador da Web enquanto aprendia os conceitos básicos de Golang e logo tinha algo que poderia mostrar a Rémy, CTO da Weglot. 

Não era grande coisa, um programa simples que recebia um URL como entrada e começava a rastrear o site, visitando todos os links do mesmo domínio que encontrava, mas era rápido e eficiente.

Após uma rápida demonstração, Rémy ficou entusiasmado com a solução fornecida e com o tempo necessário para pesquisa e desenvolvimento para finalizar o POC (prova de conceito) e, em seguida, pensar em como poderíamos hospedar a solução para uso futuro na produção.

Como engenheiro de software, é muito bom quando você trabalha em algo por conta própria e depois recebe tempo para desenvolver totalmente o seu produto. É uma ótima sensação de reconhecimento e isso me motivava até que tivéssemos um produto pronto para produção(o que ainda faltava muito).

O problema da hospedagem

Além de terminar o bot, que ainda precisava do recurso de geração de conteúdo e de algum trabalho adicional para levar em conta as diferenças entre diferentes CMS e integrações, comecei a pensar em como poderíamos hospedar e expor o bot aos nossos usuários.

Minha primeira ideia foi usar a solução clássica e bem comprovada: rodar uma instância de computação no AWS e expor o bot por trás de um servidor da Web. Parecia uma boa ideia, mas quanto mais eu pensava sobre isso, mais me preocupava com vários problemas.

Primeiro, eu não tinha ideia da carga que o servidor teria que assumir e de quantos usuários usariam o recurso ao mesmo tempo. E se a capacidade provisionada for suficiente, mas de repente você tiver muitos usuários rastreando diferentes sites muito grandes ao mesmo tempo?

Como eu não tinha experiência anterior com a hospedagem de um programa em Go, era difícil determinar quais recursos (CPU, RAM...) seriam suficientes para proporcionar uma ótima experiência ao usuário.

Além disso, eu achava que o clássico servidor da Web "sempre ativo" não era a solução mais eficiente. As pessoas não estariam rastreando o site o tempo todo: depois de importar os URLs e gerar o conteúdo, você não deve usar o bot diariamente, mesmo que publique conteúdo novo/atualizado com frequência.

Pensando nisso, começou a parecer um caso de uso perfeito para a hospedagem sem servidor.

Para aqueles que não perceberam a tendência sem servidor há alguns anos, vou resumir rapidamente como ela funciona:

• Apesar do nome sem servidor, o código ainda é executado em um servidor
• Ao contrário de um servidor, que está sempre em execução e aguardando conexões, o código sem servidor é executado sob demanda. Quando o código sem servidor é acionado, o provedor de nuvem provisiona e aloca alguns recursos para o código ser executado.

Esse modelo de hospedagem apresenta imediatamente duas vantagens principais:

• Os desenvolvedores não precisam gerenciar a infraestrutura, pois tudo isso é feito pelo provedor. Isso significa que você não precisa se preocupar com a segurança ou a configuração do servidor.
• O mais importante é que ele é dimensionável por design! 

Lembra quando eu disse que era difícil prever quais recursos um servidor precisaria para executar o bot? Para cada solicitação, um novo contêiner isolado e sem estado é criado para executar seu código dentro dele. Não há risco de exceder a capacidade do servidor, pois cada solicitação recebe seu próprio contêiner para ser executada.

Então, tudo é para o melhor no melhor de todos os mundos possíveis? Bem, quase!

Em 2020, a computação sem servidor era limitada a 5 minutos (pelo menos para a AWS, não tenho experiência com hospedagem sem servidor no Google Cloud Platform ou no Microsoft Azure). Isso faz todo o sentido, pois esse modelo de hospedagem foi projetado para tarefas curtas, como gerar um PDF ou cortar imagens, por exemplo. 

Em nosso caso, porém, a duração de 5 minutos foi um problema difícil. Embora seja mais do que suficiente para rastrear um site pequeno e de resposta rápida, ele certamente atingiria o limite antes de concluir a tarefa para sites grandes de comércio eletrônico, que podem facilmente ter dezenas de milhares de páginas e, às vezes, são um pouco lentos para responder.

Eu estava prestes a desistir do serverless quando a AWS fez um anúncio no início de 2020 - eles aumentariam o limite de 5 minutos para 15 minutos! 

Infelizmente, como costuma acontecer com a AWS, eles não fornecem muitas informações sobre os novos recursos quando os anunciam. O limite de tempo foi estendido, mas não houve explicações sobre como obtê-lo.

Vou poupar você das muitas tentativas, erros e pesquisas que fiz para descobrir como estender o limite para 15 minutos, mas garanto que não foi fácil 🙂

O limite de 5 minutos era, na verdade, um limite imposto no nível da infraestrutura, o AWS não manterá uma conexão HTTP por mais de 5 minutos entre seus diferentes serviços. A solução era simplesmente não acionar o código sem servidor com uma chamada HTTP, há muitas outras maneiras; no nosso caso, configuramos um acionamento com o SQS: o serviço de enfileiramento de mensagens do AWS.

Comunicação dos resultados

Depois que o problema de hospedagem foi resolvido, havia mais uma tarefa a ser concluída antes que pudéssemos encerrar o dia. 

Até agora, tínhamos um bot em funcionamento, hospedado de forma escalonável e econômica, e a última coisa de que precisávamos era enviar os dados produzidos pelo bot de volta aos usuários.

Como eu queria que o recurso fosse o mais interativo possível, optei por comunicações em tempo real entre o bot e o painel de controle Weglot .

O tempo real não é obrigatório para esse tipo de recurso, você sempre pode se contentar com uma solução mais simples, como uma enquete longa, mas eu queria ter certeza de que nossos usuários receberiam feedback assim que o rastreador começasse seu trabalho e, sejamos honestos, também era uma maneira de deixar o bot brilhar e mostrar seu potencial 🙂

Como não tínhamos nada para lidar com comunicações em tempo real naquela época (não tínhamos uso para isso), decidimos optar por uma solução comprovada, escrevemos um servidor de websocket simples em nodejs e o hospedamos em uma instância do AWS EC2.

Depois de algum trabalho no bot para implementar a comunicação com o servidor websocket e para automatizar a implantação, finalmente estávamos prontos para passar para os testes antes de liberar para a produção.

O que começou como um projeto paralelo acabou se transformando em um painel de controle. 

Eu me diverti muito escrevendo o rastreador e resolvendo os vários problemas que encontrei. No final, também aprendi muito: uma nova linguagem de programação e novas habilidades no ecossistema da AWS.

Go é definitivamente uma linguagem que usarei novamente, pois ela realmente se destaca em tarefas de rede e programação cooperativa. Também é uma linguagem muito boa para ser combinada com a computação sem servidor devido ao seu baixo consumo de memória em comparação com linguagens como Js, PHP ou Python.

Como o bot abriu novas perspectivas para nós, temos alguns planos para o futuro. Estamos planejando reescrever nossa ferramenta de contagem de palavras para torná-la mais eficiente e eficaz, e também podemos usá-la para aquecer o cache (preenchê-lo com dados).

Espero que você tenha gostado dessa espiada na tecnologia da Weglottanto quanto eu gostei de escrever este artigo.