Mini-catalogue de cinéma
Supinfo.TV V1
Mini-catalogue de cinéma en web statique : accueil par rayons, catalogue alphabétique de 34 films et recherche à suggestions instantanées, avec fiches détaillées alimentées par l'API OMDb.
Le projet
L'exercice imposait de manipuler une API externe en JavaScript pur. J'ai choisi une interface de plateforme de streaming parce que c'est le cas d'usage qui condense tous les vrais problèmes du front : des données asynchrones qui arrivent en désordre, des images qui peuvent manquer, une recherche qui doit répondre pendant la frappe, et une API gratuite dont il faut respecter le quota.
Trois pages, 34 films, aucune bibliothèque externe : tout est écrit à la main, du tri alphabétique à la modale de fiche film.
Ce projet a servi de base à Supinfo.TV V2, qui reprend l'idée pour en faire une plateforme e-commerce complète.
Fonctionnalités
- Accueil par rayons : trois catégories, tirage aléatoire et bouton pour rebrasser la sélection
- Catalogue trié alphabétiquement, avec une barre latérale A–Z qui se surligne au défilement
- Recherche tolérante aux fautes de frappe, avec suggestions en temps réel
- Fiche film en modale construite dynamiquement, avec notes ramenées sur 5 et dates en français
Les difficultés rencontrées
La clé OMDb gratuite est plafonnée à 1000 requêtes par jour, et ma page catalogue en lançait 34 à chaque rechargement : quelques dizaines de rafraîchissements en développement suffisaient à épuiser le quota, et la page devenait vide. S'ajoutait un second problème : l'API ne renvoyait pas d'affiche pour certains films, ce qui laissait des cadres cassés dans la grille. J'ai traité les deux séparément : réduire le nombre d'appels, et ne jamais dépendre d'une source unique pour une donnée. Les 34 requêtes partent désormais en parallèle avec Promise.allSettled plutôt que Promise.all : le choix est délibéré, car si trois films échouent les 31 autres s'affichent quand même, là où Promise.all aurait tout fait tomber. Le résultat est ensuite mis en cache dans le navigateur, si bien que les rechargements suivants ne consomment plus une seule requête. Enfin, j'ai construit une chaîne de repli : l'API, puis un fichier local de 34 fiches que j'ai rédigées à la main, puis une affiche locale, puis une image par défaut. Résultat : en coupant le réseau, le site reste utilisable en mode dégradé.
Pour les affiches, le JavaScript côté navigateur ne peut pas vérifier si un fichier existe. J'ai contourné en enveloppant le chargement de l'image dans une promesse résolue par ses propres événements de succès ou d'échec : je tente le format le plus léger, puis les suivants, et je garde le premier qui répond.
Ce que j'en ai retiré
- Le vrai travail du front n'est pas le cas nominal, mais tout ce qui l'entoure : le quota dépassé, l'image absente, la réponse partielle.
- La différence entre Promise.all et Promise.allSettled, comprise sur un cas concret où elle faisait la différence entre une page vide et une page presque complète.
- Le cache n'est pas une optimisation de confort mais la condition pour que le service reste utilisable.
- Ma clé d'API est écrite en dur dans le JavaScript, donc visible par quiconque ouvre les sources. C'est acceptable ici (clé gratuite, projet d'école), mais j'en ai retenu que dès qu'une clé a de la valeur, il faut un serveur qui fasse le relais.
- Travailler à deux sans répartition claire nous a coûté du temps : nous touchions tous les deux au front comme au back, sans que personne ne soit vraiment responsable d'une partie. Sur Supinfo.TV V2, mené avec le même binôme, nous avons cette fois séparé nettement les périmètres et défini les points d'échange entre eux. La différence de fluidité a été nette.