Docker, TypeScript, PostgreSQL, Prisma, React, Redux | projet de formation O’Clock pour le Titre Professionnel CDA

Live Demo

Présentation

ZombieLand, jeune parc d’attractions à succès, avait besoin d’un site en ligne qui fournirait aux visiteurs un aperçu captivant du parc tout en leur offrant la possibilité de réserver des billets en ligne. Les enjeux essentiels était donc la sécurisation des commandes et des paiements et le confort d’utilisation du site.

Conçues et développées avec trois autres camarades, les fonctionnalités développées en 4 semaines (4 sprints selon la méthode Agile Scrum) sont :

• Pages de présentation (accueil, activités, mentions légales, contact)
• Espace utilisateur : inscription, connexion, gestion du compte et des réservations
• Tunnel de commande pour réserver ses billets : choix du tarif, nombre de places, date
• Paiement sécurisé via Stripe + suivi des statuts via IPN
• Backoffice admin : gestion des commandes, utilisateurs, tarifs, activités et catégories
• Génération de QR Code pour les billets
• Facture PDF
• Formulaire de contact + envoi d’emails (confirmation, mot de passe oublié…)
• Avis et notes sur les activités

Pour la conception, nous avons déclinés les fonctionnalités en User Stories puis en diagrammes UML pour anticiper en amont du développement toutes les routes API et les URL nécessaires côté Back-end et Front-end. L’arborescence du site et les wireframes ont pu donc être détaillés dès cette étape.

Architecture API Rest / SPA

Nous avons choisi de séparer complétement le Back-end du Front-end afin que l’indépendance totale de chaque partie facilite leur développement parallèle et renforce leur autonomie s’il l’une d’elle doit être mise à jour. Aussi ce découplage permet de pouvoir développer plusieurs applications sur différents supports, notamment sur mobile, tout en conservant une seule API pour la sécurisation et la gestion des données.

Côté Back-end, nous avons commencé par modéliser les données à partir des User Stories, pour stocker les entités dont les données peuvent être amenées à évoluer dans le temps et dont on souhaite conserver une trace. Les entités et leurs attributs ont été détaillés en tables, propriétés et types de données grâce à ces schémas et au dictionnaire de données. L’utilisation de l’ORM Prisma a facilité l’écriture de la structure de la base de données et renforcer la sécurité lors des interactions de l’application avec cette dernière. Pour structurer ces interactions, nous n’avons pas utiliser GraphQL car une simple API REST et ses méthodes HTTP sont largement suffisantes pour l’ensemble des requêtes CRUD nécessaires.

Côté front-end, afin d’optimiser l’expérience utilisateur, nous avons choisi de partir sur une application rendue côté navigateur (CSR – Client Side Rendering) avec React sans rechargement complet de page lors de la navigation (SPA – Single Page Application). Pour gérer les données côté navigateur sous forme de cache et ainsi optimiser les requêtes et les données issues de l’API, nous avons utiliser Redux qui permet de créer et mettre à jour l’état global (un “store”) de l’application.

Enfin, nous avons mis en place beaucoup de bonnes pratiques, de documentation (OpenAPI Swagger) et d’outils d’analyses (ESLint, Prettier) et de vérification (pré-commit, validations Zod), de surveillance (monitoring et logs) et de tests (unitaires et d’intégrations) pour s’assurer d’une qualité constante et de non-régressions et ainsi anticiper toutes failles potentielles de sécurité. Comme Git et Docker ont été utilisé dès le début du développement pour définir un environnement stable et commun, l’intégration continue et le déploiement de l’API et de l’application ont pu être écrits facilement via un script YAML, configuré avec GitHub Action pour être déclenché à l’envoie du code sur la branche Git de production.

Challenges

J’ai appris énormément lors de la réalisation de ce projet qui m’a permis non seulement d’assimiler beaucoup d’outils et de concepts vus en cours mais également d’approfondir certains aspects du développement d’application, notamment la gestion de conteneurs Docker, l’utilisation de Redux, la mise en place de script de pré-commits et de CI/CD (GitHub Action).

La mise en place de Docker n’a pas été simple. Nous avons écrit à deux les fichiers “docker-compose” et “Dockerfile” pour le back-end, et avons réussi à faire tourner le projet avec 3 services (“zombieland-db”, “zombieland-api”, “adminer”). Mais lors du développement des premières routes, impossible de voir les modifications dans le client HTTP, alors que le script npm inclus bien le mode “watch” (“tsx –watch index.ts”). En me renseignant un peu j’ai compris qu’il manquait un volume de type “bind” au service “zombieland-api”. (Avec un volume nommé ça ne fonctionnerait pas car il est géré par Docker, ne reflète pas le code local et il faudrait donc le supprimer manuellement à chaque modification du code). Comme j’avais déjà tenté il y a quelques années de comprendre le fonctionnement des conteneurs Docker, c’est une petite victoire pour moi d’enfin les maîtriser avec leurs images et leurs volumes. J’apprécie de plus en plus Docker et je pense qu’il est indispensable au même titre que Git : là où Git cadre le développement dans le temps, Docker cadre le développement dans l’espace.

En plus de Docker, je me suis donné un second challenge que j’avais également déjà tenté sans succès il y a quelques années : configurer un environnement de développement avec WSL. Pour des raisons matérielles et personnelles, je souhaite limiter le nombre de systèmes d’exploitation que j’utilise, et le développement d’applications PHP ou Node sous Windows semble beaucoup plus confortable aujourd’hui qu’il ne le fût précédemment. WSL embarque un mini-système Linux, il s’agit d’un environnement virtuel optimisé et autonome alors que depuis des années je devais utiliser des logiciels tiers comme VirtualBox, Laragon ou Laravel Herd. Pour bien utiliser WSL, l’IA générative m’a été d’un grand secours en m’indiquant l’endroit où installer les projets de développement, les lignes de commande pour débloquer certains problèmes et la distinction entre les différents terminaux Windows. La combinaison WSL + Docker me permet aujourd’hui d’avoir un environnement de développement stable, solide et polyvalent.