Strike Report

Le contexte

Destiny 2 (Bungie) propose des dizaines d'assauts (Strikes) — des missions coopératives à 3 joueurs. La communauté dispose déjà d'outils comme gm.report pour suivre les Nuits Noires, mais rien d'équivalent pour les assauts standards.

Strike Report (strike-report.com) comble ce manque : n'importe quel joueur D2 peut chercher un Gardien par son Pseudo#Code et obtenir un tableau de bord détaillé par assaut — wins, record perso, KD, runs récentes, et le détail complet de chaque PGCR (armes, capacités, kills précis).

Le site cible la communauté D2 francophone et est entièrement en français.

Fonctionnalités

• Recherche d'un Gardien par Pseudo#Code, debounced 300 ms côté React
• Profil joueur : grille de cartes par assaut (wins, record, KD, runs récentes)
• Modale PGCR : détail complet d'une run cliquée — armes par slot, capacités, kills, précisions
• Leaderboard top 10 alimenté par collecte passive en arrière-plan
• Connexion Bungie OAuth2 — le compte connecté reçoit un badge "Owner" sur son profil
• Portail Hérésie — détection automatique via activityDifficultyTier: 11, badge dédié

Architecture

L'application est découpée en deux briques qui dialoguent via JSON :

Flux d'une recherche :
Browser → Twig (shell) → React (HomeSearch) → fetch /api/... → SearchController → BungieApiService → API Bungie → Doctrine → MySQL (cache leaderboard)

Spécificités notables

• Filtrage strict des activités — ActivityFilter.php blackliste 60+ IDs (donjons, événements saisonniers, BG customize, Empire Hunts, Ketchcrash…) et exclut le mode 32 (privé) ainsi que les modes 46-47 (Nightfall).
• STRIKE_GROUPS dans strikeManifest.js — chaque assaut a des dizaines de hash IDs dans le manifeste Bungie (light=0, light=750, matchmade/non-matchmade…). Le manifeste regroupe ces variants sous un même assaut.
• Pagination parallèle + slimActivity() — pour gérer les vétérans à 500+ clears sans faire exploser la mémoire.
• Portail Hérésie — détection lazy via activityDifficultyTier: 11, badge "Via le Portail" + dots cyan sur la run.
• Auth Bungie OAuth2 complète, avec badge "Owner" sur mon propre profil (so#8098).
• Collecte passive — CronController + PlayerQueue alimentent le leaderboard en arrière-plan, hors recherches utilisateur.

Stack technique

• Backend : Symfony 8, PHP 8.4, Doctrine ORM
• Frontend : React 18, Vite 5, Tailwind CSS, Symfony UX React, Stimulus, Turbo
• Base de données : MySQL 8 (dev, via Docker) / MariaDB 10.11 (prod Infomaniak)
• Cache : Redis en dev, filesystem en prod (APCu indisponible sur l'hébergement mutualisé)
• API externe : Bungie API (OAuth2, rate-limit 30 req/min)
• SEO : meta dynamiques, OG/Twitter Cards, sitemap.xml, robots.txt, pages 404 "Gardien introuvable" + 500 custom

Ce que j'en retire

Premier projet perso à cette échelle : auth OAuth2 complète sur une API tierce avec rate-limit, optimisation mémoire pour les comptes vétérans, et architecture full-stack Symfony + React montée from scratch.

Le plus formateur : gérer la dette d'un manifeste opaque. L'API Bungie ne livre pas un assaut, elle livre des hashs d'activités. Comprendre que des dizaines de hashs pointent vers la même mission (selon la difficulté, le matchmaking, l'événement saisonnier) a demandé un effort de modélisation important — d'où l'existence du STRIKE_GROUPS.

Aussi, basculer du cache APCu au cache filesystem dans le dernier commit m'a appris qu'il faut tester sur le vrai environnement d'hébergement tôt — pas seulement en local Docker.