En 2021, j’ai conçu et développé une interface web dédiée à la gestion des événements d’une guilde MMO répartie sur plusieurs jeux. L’objectif était de centraliser les plannings, les effectifs et les rôles sur une seule application, tout en conservant une grande flexibilité métier selon les jeux concernés.
Ce projet m’a amené à travailler en stack full JavaScript, avec Nuxt 2 pour le front et Strapi comme CMS headless pour le back.
Architecture du projet
Front-end : Nuxt 2 + Vuetify
Le front reposait sur Nuxt 2, avec les choix techniques suivants :
- Vue 2 avec Options API, découpé en pages (
pages/jeu/_slug.vue,pages/evenements/index.vue) et composants métiers réutilisables. - Vuetify comme framework UI principal, pour bénéficier d’une grille responsive, d’un système de thèmes et de composants prêts à l’emploi (modales, data tables, date pickers…).
- Routing dynamique basé sur le nom des jeux pour basculer entre univers (ex.
/jeu/guild-wars-2,/jeu/lost-ark). - Gestion des états via Vuex, avec des modules (
event.js,character.js,auth.js) organisés par domaine fonctionnel, et des actions asynchrones pour les appels à l’API Strapi. - Authentification JWT avec persistence via
localStorageet injection automatique des headersAuthorizationdans les requêtes. - Theming Vuetify personnalisé pour coller à l’univers gaming de la guilde : fond sombre, accent color néon, avatars ronds, typographie pixel.
Back-end : Strapi + MongoDB sur Heroku
Le back-office reposait sur un Strapi 3.x, connecté à une base MongoDB (MongoDB Atlas), et hébergé sur Heroku.
- Les contenus étaient modélisés dans Strapi sous forme de collections custom :
jeu,personnage,evenement,utilisateur. - MongoDB offrait une bonne souplesse pour stocker des structures variées selon les jeux : chaque jeu pouvait avoir ses propres rôles, formats d’événements ou types de personnages.
- L’API REST de Strapi permettait de requêter facilement les relations imbriquées (
populate=deep) pour afficher tous les personnages inscrits à un événement, par exemple. - Insomnia servait d’outil de test pour les endpoints, la vérification des rôles utilisateurs, et la préparation des appels front → back avant intégration.
- L’auth Strapi utilisait JWT, avec des rôles personnalisés créés directement depuis l’interface admin.
Intégration et logique métier
Côté Nuxt, l’intégration passait par des requêtes fetch à l’API Strapi avec une gestion centralisée des headers Authorization via runtime config.
Les endpoints de Strapi ont été étendus avec des permissions custom pour restreindre certaines actions (ex : seuls les officiers pouvaient créer des événements, les membres ne pouvaient modifier que leurs propres personnages).
Un point clé a été l’utilisation de la sérialisation de Strapi pour populer dynamiquement les relations, notamment les auteurs des contenus. Par exemple, la requête : /evenements?populate[author]=* permettait de récupérer directement, pour chaque événement, les métadonnées liées à son créateur (pseudo, rôle, ID), sans requête supplémentaire côté client.
Enseignements
Ce projet m’a fait sortir du rôle « classique » de dev front. Sur un projet perso, on ne peut pas se contenter de consommer une API : il faut la modéliser, la maintenir, la sécuriser.
Strapi a joué un rôle essentiel en me permettant de concentrer mes efforts sur le front tout en structurant un back propre et évolutif. Sans framework lourd ni ORM (Object-Relational Mapping) à la main, j’ai pu déployer rapidement un back-office customisé et exploitable en production.
En tant que développeur front-end, ce genre de projet rappelle que le découpage back/front est parfois une vue d’esprit. Quand on est seul ou en petite équipe, comprendre la logique de données et les règles métiers côté serveur est indispensable.
Liens utiles :
https://docs.strapi.io/#introduction
https://github.com/Brumes-RP (le projet est mort, il ne reste que le repo)