Aller au contenu
learn

Spring Boot, Spring Cloud et Reactor pour développeurs C# — Mission

Le cours Java m’a appris le langage. Pourtant, le code Java que je rencontre vraiment est rarement du Java pur : c’est un service Spring Boot, souvent réactif, derrière une passerelle Spring Cloud. Ses annotations font le travail que Program.cs fait explicitement dans ASP.NET Core, et ses Mono et Flux ressemblent à Task et IAsyncEnumerable sans se comporter comme eux.

Je veux lire et écrire ces services avec la même assurance qu’une application ASP.NET Core : savoir d’où vient chaque bean, prédire sur quel thread s’exécute un pipeline, et distinguer un vrai choix de conception d’une simple habitude.

Vous êtes un développeur C# expérimenté. Vous connaissez ASP.NET Core, son injection de dépendances, IOptions, IHostedService, les health checks, HttpClient, IAsyncEnumerable, et probablement Polly et YARP. Vous avez suivi Java pour développeurs C#, ou vous êtes à l’aise avec Java 25, Maven et JUnit. Ce cours vous renvoie aux leçons de ce cours-là au lieu de les répéter : la leçon 9 pour les threads virtuels, la leçon 10 pour Maven, la leçon 11 pour JUnit, Mockito et BlockHound.

Les leçons construisent de petits services autour de la théorie musicale : un service de gammes qui renvoie les notes et les accords d’un mode, un flux de progressions, un client de grilles d’accords. Le domaine est un module Java ordinaire, music, sans Spring ni Reactor. À la fin du cours, les pièces s’assemblent ainsi :

flowchart LR
client[Navigateur ou client HTTP] --> gateway[Spring Cloud Gateway]
gateway --> scales["Service des gammes (WebFlux)"]
gateway --> progressions["Service des progressions (server-sent events)"]
progressions -->|WebClient| scales
scales --> db[(Base de données R2DBC)]
config[Serveur de configuration] -.-> scales
config -.-> progressions
progressions -->|Spring Cloud Stream| broker[[Broker de messages]]

Les leçons 1 à 4 construisent les deux premières boîtes de droite ; les leçons suivantes ajoutent les autres. Tout tourne sur localhost, démarré par les tests, sans Docker.

  • créer une application Spring Boot et expliquer d’où viennent chacun de ses beans, de ses propriétés et de ses endpoints ;
  • transposer l’injection de dépendances, la configuration, les options et les health checks d’ASP.NET Core vers ceux de Spring ;
  • écrire, tester et déboguer des pipelines Reactor, et dire sur quel thread s’exécute chaque étape ;
  • choisir entre Spring MVC sur threads virtuels et WebFlux pour un service donné ;
  • construire des API HTTP et des clients réactifs avec WebFlux et WebClient ;
  • placer devant ces services une passerelle, une configuration centralisée, la découverte de services et la résilience avec Spring Cloud ;
  • observer et tester un ensemble de services Spring comme je le ferais pour un ensemble de services ASP.NET Core.
# Leçon Vous connaissez déjà
1 Spring Boot vu depuis ASP.NET Core Program.cs, IServiceCollection, appsettings.json, IOptions, health checks
2 Reactor : Mono et Flux Task, IAsyncEnumerable, LINQ, Rx.NET
3 Reactor sous le capot le pool de threads, ConfigureAwait, les channels, Polly, AsyncLocal
4 WebFlux minimal APIs, HttpClient, server-sent events
5 Accès réactif aux données avec R2DBC et Spring Data Entity Framework Core, IAsyncEnumerable depuis un DbContext
6 Spring Cloud Gateway YARP
7 Configuration centralisée avec Spring Cloud Config fournisseurs de configuration, Azure App Configuration
8 Découverte de services et répartition de charge côté client découverte de services de .NET Aspire, IHttpClientFactory
9 Résilience avec Resilience4j et Spring Cloud Circuit Breaker Polly, Microsoft.Extensions.Http.Resilience
10 Messagerie avec Spring Cloud Stream MassTransit, clients Azure Service Bus
11 Observabilité avec Micrometer OpenTelemetry pour .NET, dotnet-counters
12 Tester un ensemble de services Spring WebApplicationFactory, tests d’intégration

Journal : ce que j’ai essayé, ce qui m’a surpris, ce qu’il me reste à vérifier.