Categorygithub.com/corentin35000/crypto-viz-scraper
repository
0.0.0-20250205181843-da43b778d63e
Repository: https://github.com/corentin35000/crypto-viz-scraper.git
Documentation: pkg.go.dev
Overview
Dependencies
0
Dependents
0

# Packages

No description provided by the author

# README

Crypto Viz - Scraper

🛠 Tech Stack

  • Go (Language)
  • Colly (Library)
  • CI / CD (Github Actions)
  • DockerCompose (Development-Local)
  • Kubernetes (Development-Remote, Staging and Production)





🏗️ Architecture de l'Application

Ce projet est structuré en quatre dépôts distincts, chacun jouant un rôle essentiel dans la collecte, le traitement et la visualisation des données. En suivant une architecture microservices, chaque dépôt est un composant indépendant, permettant une flexibilité et une maintenabilité optimales. Cette architecture modulaire permet également des mises à jour, des tests et des déploiements continus sans interférer avec les autres parties de l'application.


Schéma d’Architecture

Schéma d’architecture du projet Crypto Viz


Composants et Responsabilités

1. Frontend : crypto-viz-frontend

  • Rôle : Fournit l'interface utilisateur (UI) pour visualiser en temps réel les données et analyses relatives aux cryptomonnaies.
  • Technologies : Développé avec Nuxt et TypeScript, il intègre des bibliothèques de visualisation comme apexchart et chart.js pour afficher les données.
  • Responsabilité : Le frontend consomme 3 sources de données :
    • Les API des plateformes de marché pour obtenir les données de marché et les analyses.
    • L'API du backend pour récupérer les actualités passé lors du chargement de la page la première fois
    • Le broker de messages pour recevoir les actualités filtrées du backend en temps réel.

2. Scraper : crypto-viz-scraper

  • Rôle : Ce composant se charge de collecter en temps réel les informations depuis un flux d'actualités sur les cryptomonnaies.
  • Technologies : Construit en Go avec la bibliothèque Colly, qui permet de gérer efficacement un nombre important de requêtes simultanées grâce au parallélisme et à la gestion de la mémoire, en offrant de meilleures performances pour les scrapers intensifs.
  • Responsabilité : Ce service fonctionne en continu et publie les actualités recueillies sur le broker de messages (crypto-viz-broker). En tant que producteur dans le modèle producteur/consommateur, il assure un flux constant de données.

3. Backend : crypto-viz-backend

  • Rôle : Analyse les données collectées par le scraper, filtre les informations pertinentes et les transforme pour les rendre exploitables par le frontend.
  • Technologies : Construit avec AdonisJS, un framework backend offrant une structure complète pour la gestion des APIs et la logique métier.
  • Responsabilité :
    • Consomme les données via le broker de messages, filtre, sauvegarde en base de donnée.
    • Publie les actualités filtrées sur un sujet dédié pour le frontend.
    • Expose une API pour récupérer les actualités filtrées lors de la première fois.

4. Broker : crypto-viz-broker

  • Rôle : Assure la communication entre le scraper, le backend, et le frontend en utilisant un système de messages.
  • Technologies : Utilise NATS comme broker de messages, permettant une gestion performante et asynchrone des flux de données.
  • Responsabilité :
    • Gère la distribution des messages entre les services en maintenant un flux de données continu entre les composants.
    • Permet au scraper de publier des messages de manière indépendante, que le backend peut consommer et analyser.
    • Facilite la scalabilité en permettant d'ajouter des instances supplémentaires de chaque composant sans créer de dépendances directes.

Déroulement des Données et Interactions

  1. Le scraper publie les dernières actualités sur le sujet crypto.news du broker.
  2. Le backend souscrit au sujet crypto.news, filtre et traite les informations, puis publie les actualités filtrées et enrichies sur un nouveau sujet crypto.news.filtered.
  3. Le frontend souscrit au sujet crypto.news.filtered pour obtenir en temps réel les informations actualisées.
  4. Pour les données de marché, le frontend interroge directement les plateformes du marché via des appels HTTP.

Avantages de cette Architecture

  • Indépendance des Composants : Chaque service est autonome et peut être mis à jour, redémarré ou mis à l’échelle indépendamment.
  • Scalabilité : Le broker de messages permet d’ajouter des instances supplémentaires de chaque service pour gérer une charge accrue sans modification de l'architecture.
  • Temps Réel : Le modèle producteur/consommateur via NATS permet des communications en temps réel, assurant que les utilisateurs disposent toujours des données les plus récentes.
  • Flexibilité : La séparation des responsabilités permet d'ajuster ou de remplacer un composant sans perturber le reste du système.





📁 Organisation du Code Source du Scraper

crypto-viz-scraper/
├── Dockerfile # Instructions pour construire l'image Docker
├── docker-compose.yml # Configuration Docker Compose pour lancer l'application
├── .air.toml # Configuration d'Air pour le rechargement automatique en développement
├── go.mod # Dépendances Go du projet
├── go.sum # Vérification d'intégrité des dépendances Go
└── src/ # Code source de l'application
├── main.go # Point d'entrée de l'application
├── collector.go # Configuration et gestion du collecteur Colly
├── processor.go # Logique du scraper
├── nats.go # Service Nats pour le broker de message





📦 Versionning

On utilise la convention SemVer : https://semver.org/lang/fr/

Pour une Release classique : MAJOR.MINOR.PATCH
Pour une Pre-Release, exemples : MAJOR.MINOR.PATCH-rc.0 OR MAJOR.MINOR.PATCH-beta.3

Nous utilison release-please de Google pour versionner, via Github Actions.
Pour que cela sois pris en compte il faut utiliser les conventionnal commits : https://www.conventionalcommits.org/en/v1.0.0/
Release Please crée une demande d'extraction de version après avoir remarqué que la branche par défaut contient des « unités publiables » depuis la dernière version. Une unité publiable est un commit sur la branche avec l'un des préfixes suivants : feat / feat! et fix / fix!.

La première Release que créer release-please automatiquement est la version : 1.0.0
Pour créer une Pre-Release faire un commit vide, par exemple si on'ai à la version 1.0.0, on peut faire :

git commit --allow-empty -m "chore: release 1.1.0-rc.0" -m "Release-As: 1.1.0-rc.0"





🚀 Conventions de Commit

Nous utilisons les conventions de commit pour maintenir une cohérence dans l'historique du code et faciliter le versionnement automatique avec release-please. Voici les types de commits que nous utilisons, ainsi que leur impact sur le versionnage :

  • feat : Introduction d'une nouvelle fonctionnalité pour l'utilisateur. Entraîne une augmentation de la version mineure (par exemple, de 1.0.0 à 1.1.0).

  • feat! : Introduction d'une nouvelle fonctionnalité avec des modifications incompatibles avec les versions antérieures (breaking changes). Entraîne une augmentation de la version majeure (par exemple, de 1.0.0 à 2.0.0).

  • fix : Correction d'un bug pour l'utilisateur. Entraîne une augmentation de la version patch (par exemple, de 1.0.0 à 1.0.1).

  • fix! : Correction d'un bug avec des modifications incompatibles avec les versions antérieures (breaking changes). Entraîne une augmentation de la version majeure.

  • docs : Changements concernant uniquement la documentation. N'affecte pas la version.

  • style : Changements qui n'affectent pas le sens du code (espaces blancs, mise en forme, etc.). N'affecte pas la version.

  • refactor : Modifications du code qui n'apportent ni nouvelle fonctionnalité ni correction de bug. N'affecte pas la version.

  • perf : Changements de code qui améliorent les performances. Peut entraîner une augmentation de la version mineure.

  • test : Ajout ou correction de tests. N'affecte pas la version.

  • chore : Changements qui ne modifient ni les fichiers source ni les tests (par exemple, mise à jour des dépendances). N'affecte pas la version.

  • ci : Changements dans les fichiers de configuration et les scripts d'intégration continue (par exemple, GitHub Actions). N'affecte pas la version.

  • build : Changements qui affectent le système de build ou les dépendances externes (par exemple, npm, Docker). N'affecte pas la version.

  • revert : Annulation d'un commit précédent. N'affecte pas la version.

Pour indiquer qu'un commit introduit des modifications incompatibles avec les versions antérieures (breaking changes), ajoutez un ! après le type de commit, par exemple feat! ou fix!.

Pour plus de détails sur les conventions de commit, consultez : Conventional Commits





📚 Domains of different environments





⚙️ Setup Environment Development

  1. Clone the project repository using the following commands :
git clone [email protected]:corentin35000/crypto-viz-scraper.git
  1. Steps by Platform :
# Windows :
1. Requirements : Windows >= 10
2. Download and Install WSL2 : https://learn.microsoft.com/fr-fr/windows/wsl/install
3. Download and Install Docker Desktop : https://docs.docker.com/desktop/install/windows-install/

# macOS :
1. Requirements : macOS Intel x86_64 or macOS Apple Silicon arm64
2. Requirements (2) : macOS 11.0 (Big Sur)
2. Download and Install Docker Desktop : https://docs.docker.com/desktop/install/mac-install/

# Linux (Ubuntu / Debian) :
1. Requirements : Ubuntu >= 20.04 or Debian >= 10
2. Download and Install Docker (Ubuntu) : https://docs.docker.com/engine/install/ubuntu/
3. Download and Install Docker (Debian) : https://docs.docker.com/engine/install/debian/





🔄 Cycle Development

  1. macOS / Windows : Open Docker Desktop
  2. Run command :
   docker-compose up





🚀 Production

⚙️➡️ Automatic Distribution Process (CI / CD)

Si c'est un nouveau projet suivez les instructions :

  1. Ajoutées les SECRETS_GITHUB pour :
    • DOCKER_HUB_USERNAME
    • DOCKER_HUB_ACCESS_TOKEN
    • KUBECONFIG
    • PAT (crée un nouveau token si besoin sur le site de github puis dans le menu du "Profil" puis -> "Settings" -> "Developper Settings' -> 'Personnal Access Tokens' -> Tokens (classic))