Backend microservices (Spring Cloud, gateway, services métier) et développement de l'application cliente Flutter

Plateforme de dons — microservices et application cliente

Gateway Spring Cloud + Eureka et services métier (auth, donation, organisation, mail…) derrière un registre.

11+
services métier
Eureka
service discovery
Gateway
entrée HTTP unique

Contexte

Backend multi-modules Java 17 / Spring Boot 3.1 / Spring Cloud 2022.0.4 ; application Flutter associée.

Le problème

Séparer auth, dons, organisations, paiements et mail dans des déploiements indépendants, avec découverte de services et entrée unique.

L'approche

  • Service registry (Eureka Server) + API gateway (Spring Cloud Gateway, client Eureka).
  • Services métier : auth, user, donation, organization, cause, testimony, activity, admin, mail, method-payment.
  • Auth avec Firebase Admin côté service-auth.
  • Client mobile Flutter consommant l'API.

Pourquoi ce choix

Gateway + service discovery pour router sans hardcoder les hosts de chaque service en environnement multi-process.

Résultat mesuré

  • Socle Spring Cloud (Eureka + Gateway + N services) en place
  • Application cliente Flutter branchée sur l'API
  • Aucune métrique de charge ou de SLA documentée dans le dépôt