Todo App Symfony
Apprendre Symfony et le prouver avec une application réellement en ligne : architecture MVC, conteneur Docker, déploiement sur Render et une démo publique où chaque visiteur a sa propre liste.
Le besoin
Symfony est l'un des frameworks PHP les plus demandés en entreprise, et je voulais le découvrir sur un projet concret. Le CRUD d'une liste de tâches n'était qu'un support : l'objectif était d'assimiler l'architecture MVC et de relier l'application à une base de données relationnelle avec Doctrine.
Surtout, je voulais aller jusqu'à la mise en ligne. Une application qui ne tourne que sur mon ordinateur ne prouve pas grand-chose ; une démo publique, n'importe qui peut l'essayer.
La solution
Une application de gestion de tâches développée de A à Z, seul, en une semaine :
- Back-end : architecture MVC (Modèle, Vue, Contrôleur) avec Symfony.
- Base de données : entité et migrations avec Doctrine ORM dans la première version, avant le passage en session pour la démo publique (voir mes choix).
- Front-end : vues dynamiques et réutilisables avec Twig.
- Conteneurisation : un Dockerfile sur mesure (PHP 8.2 + Apache) pour l'environnement de production.
- Déploiement : mise en ligne sur Render, d'abord avec une base PostgreSQL, retirée ensuite puisque la démo n'en dépend plus.
Mes choix techniques
Docker pour déployer
Render construit et lance l'application à partir d'une image Docker. J'ai écrit mon propre Dockerfile (PHP 8.2 + Apache, extensions nécessaires, Composer) : l'environnement de production est décrit dans un fichier et peut être reconstruit à l'identique.
MySQL en local, PostgreSQL en production (première version)
PostgreSQL est la base proposée par l'hébergeur. Doctrine m'a permis de garder l'essentiel du code, mais j'ai dû adapter la syntaxe SQL de la table des tâches.
Une démo publique stockée en session
Avec une base partagée, n'importe quel visiteur de la démo pouvait modifier ou supprimer les tâches des autres. J'ai basculé le stockage des tâches en session : chaque visiteur a sa propre liste, isolée. Le compromis, assumé : les tâches ne sont plus enregistrées en base et disparaissent à la fin de la session.
La difficulté principale
Fonctionnelle en local, l'application refusait de tourner une fois déployée sur Render : erreurs 500, puis 404 sur toutes les routes.
Un problème à la fois, un commit par correctif (l'historique Git en garde la trace) : extensions PHP
zip et intl manquantes, WORKDIR et commande de lancement absents
du Dockerfile, syntaxe SQL à adapter à PostgreSQL, puis un .htaccess pour qu'Apache envoie
les routes vers Symfony.
Des mois plus tard, une autre panne : la démo plantait à chaque redémarrage avec un « exit status 7 ». La base PostgreSQL gratuite de Render avait expiré, et le Dockerfile lançait les migrations avant Apache : sans base, le conteneur s'arrêtait. Comme la démo stocke les tâches en session, j'ai retiré les migrations du démarrage plutôt que de recréer une base devenue inutile.
Ce que je referais autrement
- Des comptes utilisateurs avec Symfony Security : chaque utilisateur aurait sa liste, enregistrée en base avec Doctrine et isolée des autres. La démo resterait sûre sans perdre la persistance.
- Des tests automatisés avec PHPUnit : le projet n'en a pas aujourd'hui.
Ce que j'ai appris
Stack technique
Technologies et outils utilisés :
Captures d'écran
