Construire notre robot d'exploration de sites web : un aperçu de la technologie de Weglot

De nombreux utilisateurs de Weglot souhaitent s'assurer que toutes les URL de leur site web sont correctement traduites(après la première couche de traduction automatique fournie par Weglot). Pour beaucoup d'entre eux, si vous possédez un site web de grande taille, traduit dans de nombreuses langues, cela peut prendre beaucoup de temps.

Nous avons également remarqué, grâce aux commentaires de nos utilisateurs, que certains d'entre eux étaient un peu désorientés lorsqu'ils lançaient leur premier projet de traduction de site web. Ils se demandaient souvent pourquoi seule l'URL de leur page d'accueil apparaissait dans la liste des traductions et pas toutes les autres pages, ou comment générer les traductions de leur contenu.

Nous savions donc qu'il y avait matière à amélioration dans ce domaine. Nous pouvions aider nos utilisateurs à embarquer plus facilement et à gérer leurs projets plus rapidement et plus efficacement, mais nous n'avions pas encore de solution.

Comme vous l'avez peut-être déjà deviné, cela a conduit au lancement de la fonctionnalité Gérer les URLs, qui permet à l'utilisateur de scanner les URLs de son site web et de générer son contenu traduit à partir du tableau de bord Weglot , de manière rapide et efficace.

Récemment, cette fonctionnalité a été déplacée de la liste des traductions vers la nouvelle page de gestion des traductions par URL, où elle a été rendue encore plus flexible et plus puissante. Nous avons donc pensé qu'il était grand temps de vous expliquer comment cette fonctionnalité a été mise en place.

Golang à la rescousse

Début 2020, le blocage dû à la pandémie m'a enfin donné l'occasion de m'attaquer à l'apprentissage du langage de programmation Golang que j'avais dû repousser par manque de temps.

Golang (ou Go en abrégé) est un langage créé par Google qui connaît un grand succès depuis quelques années.

Il s'agit d'un langage de programmation compilé de manière statique, conçu pour aider les développeurs à écrire des codes rapides, robustes et simultanés. Sa simplicité permet d'écrire et de maintenir des programmes complexes et de grande taille sans sacrifier les performances : Golang peut être considéré comme l'enfant inattendu de Python et de C : (assez) facile à écrire et rapide à exécuter.

À mon avis, la meilleure façon d'apprendre un nouveau langage de programmation (ou un nouveau framework ou autre) est de trouver un bon projet pour mettre en pratique ce que vous avez appris. Ce n'est pas la tâche la plus facile : si des développeurs lisent ces lignes, ils savent à quel point cela peut être difficile. 

Un bon projet secondaire doit répondre à certaines spécifications :

• Le champ d'application doit être suffisamment large pour que le développeur puisse apprendre suffisamment de la technologie qu'il est en train d'apprendre tout en construisant le programme : imprimer "Hello world" dans la console est rarement suffisant pour maîtriser un nouveau langage.
• Le champ d'application ne doit pas être si vaste que le développeur abandonnera probablement avant d'avoir terminé le projet (nous sommes tous passés par là).
• Enfin, il faut que ce soit amusant à faire ! Programmer une liste de tâches pour la 200e fois ne sera pas très divertissant, et il y a de fortes chances que vous abandonniez dès que vous aurez réfléchi à la manière de la faire fonctionner. 
• Point bonus : le projet parallèle devrait idéalement résoudre un problème réel, ce qui permet de rester concentré sur la tâche.

Alors pourquoi est-ce que je mentionne ceci ? Alors que je réfléchissais à ce qui pourrait être un bon projet parallèle pour commencer à apprendre Golang, il m'est venu à l'esprit qu'un crawler web pourrait parfaitement correspondre à la description ci-dessus et pourrait également résoudre certains des problèmes que nous cherchions à résoudre pour les utilisateurs de Weglot .

Un crawler (souvent appelé "bot") est, dans sa forme la plus simple, un programme conçu pour visiter un site web et en extraire des informations.

Un cas d'utilisation typique d'un robot d'indexation pourrait être de découvrir et de visiter chaque page d'un site web, puis de générer un plan du site (sitemap). Ou d'indexer son contenu, comme les robots de Google par exemple.

Dans notre cas, nous avions besoin d'un outil permettant à nos utilisateurs de scanner leur site web et d'en importer toutes les URL. 

Nous étions également à la recherche d'une nouvelle façon de générer des traductions. Pour ceux qui ne connaissent pas Weglot, "générer des traductions" signifie que vos URL (et le contenu qu'elles contiennent) apparaissent dans votre liste de traductions Weglot , ce qui vous permet d'apporter des modifications manuelles aux traductions.

À ce moment-là, les utilisateurs devaient visiter leur site web dans une langue traduite pour les générer. Cette méthode fonctionne très bien lorsque votre site web ne comporte que quelques pages et que vous n'avez pas beaucoup de langues traduites, mais elle peut rapidement devenir une tâche écrasante si vous possédez un très grand site web comportant des milliers de pages.

L'idée d'utiliser un robot d'indexation pour automatiser cette tâche s'est rapidement imposée comme une solution idéale et un cas d'utilisation parfait des fonctionnalités de programmation concurrente de Golang !

En janvier 2020, j'ai donc commencé à prototyper un crawler web tout en apprenant les bases de Golang et j'ai rapidement eu quelque chose à montrer à Rémy, le directeur technique de Weglot. 

Ce n'était pas grand-chose, un simple programme qui prenait une URL en entrée et commençait à explorer le site web, en visitant tous les liens du même domaine qu'il trouvait, mais c'était rapide et efficace.

Après une rapide démonstration, Rémy a été enthousiasmé par la solution proposée et a décidé de prendre le temps nécessaire à la recherche et au développement pour finaliser le POC (proof of concept) et réfléchir ensuite à la manière dont nous pourrions héberger la solution en vue d'une utilisation future dans le cadre de la production.

En tant qu'ingénieur logiciel, c'est une sensation très agréable lorsque vous travaillez sur quelque chose par vous-même et que l'on vous accorde du temps pour développer complètement votre produit. C'est un grand sentiment de reconnaissance et cela me motivait jusqu'à ce que nous ayons un produit prêt pour la production(ce qui était encore loin d'être le cas).

Le problème de l'hébergement

En plus de terminer le bot, qui avait encore besoin de la fonction de génération de contenu et de quelques travaux supplémentaires pour prendre en compte les différences entre les différents CMS et les intégrations, j'ai commencé à réfléchir à la manière dont nous pourrions héberger et exposer le bot à nos utilisateurs.

Ma première idée a été d'utiliser la solution classique et éprouvée : faire tourner une instance de calcul sur AWS et exposer le bot derrière un serveur web. Cela semblait être une bonne idée, mais plus j'y réfléchissais, plus j'étais préoccupé par plusieurs questions.

Tout d'abord, je n'avais aucune idée de la charge que le serveur devrait supporter et du nombre d'utilisateurs qui utiliseraient la fonction en même temps. Que se passe-t-il si la capacité provisionnée est suffisante mais que vous avez soudainement de nombreux utilisateurs qui parcourent différents sites web très volumineux en même temps ?

Comme je n'avais aucune expérience préalable de l'hébergement d'un programme Go, il était difficile de déterminer quelles ressources (CPU, RAM...) seraient suffisantes pour offrir une bonne expérience aux utilisateurs.

En outre, j'ai eu le sentiment que le serveur web classique "toujours en service" n'était pas la solution la plus efficace. Les gens ne parcourraient pas leur site web en permanence : une fois que vous avez importé vos URL et généré votre contenu, vous n'êtes pas censé utiliser le robot quotidiennement, même si vous publiez souvent du contenu nouveau ou mis à jour.

En y réfléchissant, cela a commencé à ressembler à un cas d'utilisation parfait pour l'hébergement sans serveur.

Pour ceux qui sont passés à côté de la tendance serverless il y a quelques années, je vais résumer rapidement son fonctionnement :

• Malgré son nom " sans serveur", le code s'exécute toujours sur un serveur
• Contrairement à un serveur, qui est toujours en cours d'exécution et à l'écoute des connexions, le code sans serveur s'exécute à la demande, lorsque le code sans serveur est déclenché, le fournisseur de cloud provisionnera et allouera certaines ressources pour que le code s'exécute.

Ce modèle d'hébergement présente d'emblée deux avantages principaux :

• Les développeurs n'ont pas à gérer l'infrastructure, c'est le fournisseur qui s'en charge. Cela signifie que vous n'avez pas à vous soucier de la sécurité ou de la configuration des serveurs.
• Et surtout, il est évolutif de par sa conception ! 

Vous vous souvenez quand j'ai dit qu'il était difficile d'anticiper les ressources dont un serveur aurait besoin pour faire tourner le bot ? Eh bien, vous n'avez plus à vous préoccuper de cela maintenant, pour chaque requête, un nouveau conteneur isolé sans état est créé pour exécuter votre code à l'intérieur, il n'y a pas de risque de dépasser la capacité du serveur, chaque requête reçoit son propre conteneur pour s'exécuter.

Alors, tout va pour le mieux dans le meilleur des mondes possibles ? Enfin presque !

En 2020, l'informatique sans serveur était limitée à 5 minutes, (du moins pour AWS, je n'ai pas d'expérience avec l'hébergement sans serveur sur Google Cloud Platform ou Microsoft Azure). C'est tout à fait logique car ce modèle d'hébergement a été conçu pour des tâches courtes comme la génération d'un pdf ou le recadrage d'images par exemple. 

Dans notre cas, la durée de 5 minutes était un problème difficile à résoudre. Si cette durée est plus que suffisante pour explorer un petit site web à réponse rapide, elle atteindrait très certainement la limite avant de terminer la tâche pour les grands sites de commerce électronique qui peuvent facilement avoir des dizaines de milliers de pages et qui sont parfois un peu lents à répondre.

J'étais sur le point d'abandonner le serverless quand AWS a fait une annonce début 2020 - ils allaient augmenter la limite de 5 minutes à 15 minutes ! 

Malheureusement, comme c'est souvent le cas avec AWS, ils ne fournissent pas beaucoup d'informations sur les nouvelles fonctionnalités lorsqu'ils les annoncent, le délai a été prolongé mais il n'y avait pas d'explications sur la façon de l'obtenir.

Je vous épargnerai les nombreux essais, erreurs et recherches que j'ai effectués pour trouver comment étendre la limite à 15 minutes, mais laissez-moi vous assurer que cela n'a pas été facile 🙂 .

La limite de 5 minutes était en fait une limite appliquée au niveau de l'infrastructure, AWS ne maintiendra pas une connexion HTTP plus de 5 minutes entre ses différents services, la solution était de simplement ne pas déclencher le code serverless avec un appel HTTP, il y a beaucoup d'autres façons, dans notre cas nous avons mis en place pour un déclenchement avec SQS : le service de mise en file d'attente des messages d'AWS.

Communiquer les résultats

Une fois le problème d'hébergement résolu, il restait encore une tâche à accomplir avant de pouvoir s'arrêter. 

Jusqu'à présent, nous disposions d'un robot fonctionnel, hébergé de manière évolutive et rentable. La dernière chose dont nous avions besoin était de renvoyer les données produites par le robot aux utilisateurs.

Comme je voulais que la fonction soit la plus interactive possible, j'ai opté pour des communications en temps réel entre le robot et le tableau de bord de Weglot .

Le temps réel n'est pas obligatoire pour ce genre de fonctionnalité, vous pouvez toujours vous contenter d'une solution plus simple comme le long polling, mais je voulais m'assurer que nos utilisateurs recevraient un feedback dès que le crawler aurait commencé son travail, et soyons honnêtes, c'était aussi une façon de laisser le bot briller et de montrer son potentiel 🙂 .

Comme nous n'avions rien pour gérer les communications en temps réel à l'époque (nous n'en avions pas l'utilité), nous avons décidé d'opter pour une solution éprouvée, nous avons écrit un simple serveur websocket en nodejs et l'avons hébergé sur une instance EC2 AWS.

Après quelques travaux sur le bot pour implémenter la communication avec le serveur websocket et pour automatiser le déploiement, nous étions enfin prêts à passer aux tests avant de passer à la production.

Ce qui n'était au départ qu'un projet secondaire a fini par être intégré au tableau de bord. 

J'ai pris beaucoup de plaisir à écrire le crawler et à résoudre les nombreux problèmes que j'ai rencontrés. Au final, j'ai également beaucoup appris : un nouveau langage de programmation et de nouvelles compétences dans l'écosystème AWS.

Go est définitivement un langage que j'utiliserai à nouveau, il brille vraiment pour les tâches de mise en réseau et la programmation coopérative. C'est également un très bon langage à coupler avec l'informatique sans serveur en raison de sa faible empreinte mémoire par rapport à des langages tels que Js, PHP ou Python.

Comme le bot nous a ouvert de nouvelles perspectives, nous avons quelques projets pour l'avenir. Nous prévoyons de réécrire notre outil de comptage de mots pour le rendre plus efficace et performant, nous pourrions également l'utiliser pour réchauffer le cache (le remplir de données).

J'espère que vous avez apprécié ce coup d'œil sur la technologie de Weglotautant que j'ai aimé écrire cet article, n'hésitez pas à essayer le bot par vous-même !