Noé Jobard

← tous les projets ← all projects

Card Market — architecture microservices

Card Market — microservices architecture

décembre 2024

December 2024

Spring BootJava 17Next.jsActiveMQ / JMSDockerNode.jsSocket.IORESTGitLab CI
Schéma d'architecture microservices de Card Market : un proxy en frontal route les requêtes utilisateur vers les services Auth, User, Card, Image generation et Properties generation ; un service Notification et un ESB relient l'ensemble à la base de données. / Card Market microservices architecture diagram: a frontal proxy routes user requests to the Auth, User, Card, Image generation and Properties generation services; a Notification service and an ESB tie everything together with the database.
Le schéma d'archi du projet : un proxy en frontal, un microservice par domaine, un ESB pour la messagerie asynchrone.
The project's architecture diagram: a frontal proxy, one microservice per domain, an ESB for asynchronous messaging.

« Card Market » — une application de marché de cartes à collectionner, conçue dans le cadre d’un projet de développement web à CPE Lyon. Le cœur de l’exercice : reprendre un monolithe Spring Boot et le découper en microservices déployables indépendamment.

Le projet

Projet de groupe (4 personnes). Les utilisateurs s’authentifient, gèrent leur collection de cartes, échangent dans un store, discutent via un chat temps réel et génèrent images / textes / propriétés de cartes via des services dédiés.

L’enjeu d’architecture : isoler chaque responsabilité — auth, utilisateurs, chat, génération, logging, matchmaking — dans son propre service, relier le tout par un bus de messages, et exposer un point d’entrée unique via un proxy.

Ce sur quoi j’ai travaillé

  • Authentification & utilisateurs — service ms-auth (Spring Boot) et CRUD utilisateurs en JPA/H2, exposés en REST.
  • Chat temps réel — backend Node.js + Socket.IO (room générale et rooms privées), avec persistance des messages côté Spring.
  • Services de génération — image, texte et propriétés de cartes, chacun un microservice Spring Boot indépendant.
  • Communication inter-services — REST synchrone (RestTemplate, axios) et messaging asynchrone via ActiveMQ / JMS pour découpler producteurs et consommateurs (logging).
  • Frontend — front HTML/JS de l’atelier initial, puis migration vers Next.js + React + Redux ; comparatif des frameworks frontend.
  • Schéma d’architecture de la nouvelle application distribuée.

La stack

Java 17 + Spring Boot (Web, Data JPA, JMS), H2 en mémoire, Swagger pour la doc d’API. Côté Node.js : Express, Socket.IO et un proxy http-proxy-middleware. Front en Next.js / React / Redux Toolkit. Build Maven, pipelines GitLab CI et conteneurisation Docker.

Ce que j’en ai retenu

Le plus dur n’est pas d’écrire un microservice. C’est de les faire dialoguer.

Trois questions reviennent en permanence : quand utiliser un appel REST direct, et quand passer par un message asynchrone (ActiveMQ) ? Comment faire cohabiter proprement du code Java et du code Node.js dans le même système ? Et comment tester un parcours qui traverse cinq services à la suite ?

Surtout, j’en retiens qu’une appli découpée en dix briques coûte beaucoup plus en orchestration, en tests et en discipline qu’un monolithe. Le découpage ne vaut le coup que si chaque service a une vraie raison d’exister à part — pas juste pour faire « microservices » sur un CV.

“Card Market” — a trading-card marketplace application, built as part of a web development project at CPE Lyon. The core of the exercise: take over a Spring Boot monolith and split it into independently deployable microservices.

The project

Group project (4 people). Users authenticate, manage their card collection, trade in a store, chat in real time, and generate card images / text / properties through dedicated services.

The architectural challenge: isolate each responsibility — auth, users, chat, generation, logging, matchmaking — into its own service, connect it all via a message bus, and expose a single entry point through a proxy.

What I worked on

  • Authentication & users — ms-auth service (Spring Boot) and user CRUD in JPA/H2, exposed over REST.
  • Real-time chat — Node.js + Socket.IO backend (a general room and private rooms), with message persistence on the Spring side.
  • Generation services — image, text and card properties, each its own independent Spring Boot microservice.
  • Inter-service communication — synchronous REST (RestTemplate, axios) and asynchronous messaging via ActiveMQ / JMS to decouple producers and consumers (logging).
  • Frontend — initial HTML/JS front from the workshop, then migration to Next.js + React + Redux; a comparison of frontend frameworks.
  • Architecture diagram for the new distributed application.

The stack

Java 17 + Spring Boot (Web, Data JPA, JMS), in-memory H2, Swagger for API docs. On the Node.js side: Express, Socket.IO and an http-proxy-middleware proxy. Frontend in Next.js / React / Redux Toolkit. Maven build, GitLab CI pipelines and Docker containerization.

What I took away from it

The hard part isn’t writing a microservice. It’s making them talk to each other.

Three questions kept coming up: when to use a direct REST call, and when to go through an asynchronous message (ActiveMQ)? How do you cleanly mix Java and Node.js code in the same system? And how do you test a flow that goes through five services in a row?

Above all, I learned that an app split into ten pieces costs a lot more in orchestration, testing and discipline than a monolith. Splitting things up is only worth it if each service has a real reason to exist on its own — not just to put “microservices” on a résumé.