Au debut du developpement de mon portfolio, j'avais une idee claire : Supabase pour le backend. L'outil est seduisant sur le papier. Une base PostgreSQL hebergee, une API REST generee automatiquement, un systeme d'authentification integre, et une interface d'administration propre. Pour un projet etudiant solo, ca semblait etre la solution ideale.
Le probleme est arrive quand j'ai commence a reflechir a l'hebergement. Supabase fonctionne avec PostgreSQL, et si je voulais auto-heberger la base de donnees, j'avais besoin d'un serveur. Je n'en avais pas. L'option hebergee de Supabase existe, mais elle introduit une dependance externe que je ne voulais pas pour un projet de portfolio ou la maitrise technique est justement ce qu'on evalue.
J'ai donc pivote vers une solution que je controlais completement : une API construite avec Symfony, une base MySQL que je pouvais heberger facilement, et Doctrine comme ORM. Moins spectaculaire, mais entierement entre mes mains.
Ce que cette experience m'a appris, c'est que le choix d'un backend n'est pas qu'une question de fonctionnalites. C'est aussi une question de contraintes d'infrastructure. Supabase est une excellente solution dans le bon contexte, c'est-a-dire quand on peut se permettre de s'appuyer sur leur hebergement ou qu'on dispose d'un serveur pour le deployer soi-meme.
La migration forcee de PostgreSQL vers MySQL a aussi ete instructive. Les deux sont des bases relationnelles, mais elles n'ont pas exactement le meme comportement sur certains types de donnees, certaines contraintes, ou certaines syntaxes SQL. Doctrine abstrait une bonne partie de ces differences, mais pas toutes.
Avec le recul, je ne regrette pas ce pivot. Construire une API maison m'a force a comprendre ce que Supabase fait sous le capot. Avant, j'aurais utilise l'outil sans vraiment savoir ce qu'il resolvait. Maintenant je le sais, et je pourrais faire le choix inverse en connaissance de cause.