Valenstagram

Je voulais apprendre à concevoir une API et une application web moderne sur un vrai sujet, alors j’ai recréé Instagram, version Valence. On y retrouve les publications photo, les likes, les commentaires, les abonnements, les profils, un explorateur, les stories et des messages privés en temps réel.

Je l’ai mené seul, en plusieurs versions, pour la communauté de l’IUT de Valence.

• L’API est en FastAPI, avec SQLAlchemy 2 et Alembic sur PostgreSQL. L’authentification passe par des jetons JWT et les mots de passe sont hachés en argon2. Pillow traite les images, et la documentation OpenAPI est générée automatiquement.
• Le temps réel repose sur un broker MQTT, Eclipse Mosquitto. L’API et les navigateurs le partagent grâce à MQTT sur WebSocket.
• Le front est en Next.js avec Tailwind.
• En production, tout tourne avec Docker Compose. La base est sur un réseau interne isolé et chaque service a son healthcheck. L’image de l’API est publiée sur Docker Hub à chaque nouvelle version, et le front est redéployé sur mon serveur par SSH.
• La CI lance pylint, une analyse CodeQL chaque semaine et les tests pytest sur une base dédiée.

Le front consomme une API REST découpée par ressource, avec l’authentification, les utilisateurs, les abonnements, les publications, les likes, les commentaires et les messages.

Quand on envoie un message privé, l’API l’enregistre en base et crée la conversation si c’est le premier échange. Elle le publie ensuite sur le topic MQTT de la conversation avec une qualité de service de niveau 1, qui garantit au moins une livraison. Le navigateur, abonné en WebSocket, l’affiche aussitôt. L’API surveille aussi sa propre connexion au broker et la signale dans son healthcheck.

La première version n’était qu’un prototype en Flask. Les routes étaient mal découpées, les utilisateurs, les publications et les commentaires étaient mal typés, et l’authentification côté front était fragile.

Plutôt que d’empiler les correctifs, j’ai réécrit l’API en FastAPI, avec une validation Pydantic de bout en bout, des schémas de réponse explicites et une documentation générée. J’ai ensuite refait le front, en passant de React à Next.js pour le routage et le rendu côté serveur.

Pour le temps réel, j’ai préféré MQTT à un serveur WebSocket fait maison, parce que le broker gère déjà la diffusion, la reconnexion et la garantie de livraison. Avec le recul, j’isolerais davantage l’accès au broker depuis le navigateur, avec des identifiants propres à chaque utilisateur et délivrés par l’API.

• Une vraie méthode pour concevoir une API, avec des ressources claires, les bons statuts HTTP, de la validation et du versionnage.
• Savoir quand il vaut mieux réécrire que rafistoler, et le faire sans tout casser.
• Mes premiers pipelines CI/CD complets, du tag Git jusqu’à l’image publiée et au déploiement.
• La conviction qu’une bonne architecture se pense avant d’écrire le code.