Skip to content

Add Bouygues scraper

uj requested to merge 16-add-bouygues into main

Ajoute un scraper Bouygues Fibre.

A l'inverse des autres scrapers qui utilisent playwright, j'ai décidé d'utiliser requests. C'est une dépendance en plus mais c'est un package extrêmement répandu et relativement léger, qui ne devrait pas ajouter beaucoup de coûts à l'usage. J'utilise requests parce que Bouygues expose une API GraphQL, ce qui nous permet de récupérer des données déjà structurées, potentiellement moins sujettes au changement que le front (qui pourrait casser les XPath). Je stocke la requête GraphQL dans une constante (plutôt que dans une variable comme sur les autres scrappers), histoire de pouvoir la modifier facilement sans avoir à éditer le corps des fonctions.

J'utilise une dataclass pour avoir un typage plus fort des offres vs. des tuples, et permettre d'avoir un constructeur depuis les données GraphQL. ça rend la construction des offres plus simple, puisqu'il n'y a plus qu'à appeler cette classmethod sur la list retournée par GraphQL. On a deux méthodes pour récupérer l'ensemble des offres, parce qu'il me semble plus judicieux d'avoir un set plutôt qu'une liste, comme ce sont des offres distinctes. Mais je garde l'accession list pour avoir des types de retour similaires à ceux des autres scrapers.

L'approche utilise des classes pour encapsuler les comportements, mais on a pas d'instanciation et on peut facilement récupérer un générateur sur les offres, pour avoir une approche plus fonctionnelle derrière (en transformant le générateur à l'aide de map/ filter pour l'adapter à nos besoins).

Enfin, j'ai une petite fonction bouygues() qui encapsule tout, qui permet d'avoir un appel similaire aux autres scrappers.

J'ai un petit doute sur l'effet de retourner fibre() + [] + [] (dans orange.py par ex.) plutôt que fibre() tout court, puisque les résultats sur le front et en base sont les mêmes dans les deux cas.

Merge request reports