Accueil

Dès qu’un service doit à la fois enregistrer une donnée en base et publier un événement sur un broker, il se heurte au problème du dual write : deux systèmes, deux écritures, et aucune transaction pour les lier. Le pattern Outbox résout ce problème en écrivant l’événement dans la même base, dans la même transaction que la donnée métier, puis en le publiant de manière asynchrone. C’est une brique de base de toute architecture pilotée par les événements, des projections CQRS à l’intégration entre microservices.

En .NET, on alloue des objets sans jamais les libérer explicitement : c’est le Garbage Collector (GC) qui s’en charge. Ce confort a un prix, des pauses et du CPU consommé, et comprendre comment le GC travaille permet d’écrire du code qui lui facilite la tâche plutôt que de le combattre. Cet article ouvre le capot : générations, tas spécialisés, modes de fonctionnement, configuration et outils de diagnostic.

En .NET, chaque objet alloué sur le tas managé finit par coûter du travail au Garbage Collector, qui doit le parcourir puis libérer sa mémoire (voir la pile et le tas pour un rappel). Sur un chemin de code très sollicité (parsing, sérialisation, traitement de flux), ces petites allocations s’accumulent et deviennent visibles en latence comme en CPU. Span<T>, ReadOnlySpan<T> et Memory<T> permettent de manipuler des portions de mémoire sans copier ni allouer, tout en restant dans du code C# sûr.

gRPC est taillé pour la communication entre services : contrat .proto, messages Protobuf binaires, transport HTTP/2. Mais un navigateur ne peut pas appeler directement un service gRPC, faute d’accès aux frames et aux trailers HTTP/2 depuis JavaScript. ASP.NET Core propose deux réponses complémentaires. gRPC-Web adapte le protocole pour qu’un client navigateur (JavaScript ou Blazor WebAssembly) parle encore Protobuf. Le JSON transcoding expose les mêmes méthodes sous forme d’API REST/JSON classique, appelable avec un simple fetch. Cet article met en place les deux sur un service d’agenda d’événements et les compare.

Une fois les services gRPC en place, viennent les préoccupations transverses : journaliser chaque appel, vérifier une clé d’API, transformer les exceptions en statuts propres, ne pas attendre indéfiniment un service lent, réessayer quand un service redémarre. gRPC en .NET répond à tout cela avec les intercepteurs, les deadlines et leur propagation, les codes de statut et des retries configurables au niveau du channel. Cet article met en place ces briques une par une sur un petit service de facturation.

gRPC définit ses services dans un fichier .proto et propose quatre modes de communication : l’appel unary (une requête, une réponse, comme un appel REST classique) et trois modes de streaming. Le streaming est l’un des grands atouts du protocole : grâce à HTTP/2, un même appel peut transporter un flux de messages dans un sens, dans l’autre, ou dans les deux à la fois. Cet article implémente les trois modes de streaming en contract-first sur un service de télémétrie de capteurs : .proto, serveur, client, annulation, et quand préférer cette approche à SSE.

« Cette version est plus rapide » : sans mesure, ce n’est qu’une intuition. Un Stopwatch autour d’une boucle donne des chiffres faussés par le JIT, le GC et le bruit du système. BenchmarkDotNet est l’outil de référence en .NET pour mesurer proprement du code : préchauffage, itérations multiples, statistiques, mesure des allocations. On l’applique ici à du code typique d’une application IoT : générer l’identifiant d’un capteur et exporter ses mesures en CSV.

Les tests unitaires vérifient la logique, pas la tuyauterie : routage, sérialisation JSON, authentification, mapping EF Core, contraintes SQL. Pour ça, il faut démarrer l’API pour de vrai, face à une vraie base de données. WebApplicationFactory héberge l’application en mémoire, Testcontainers fournit un PostgreSQL jetable dans Docker, et Respawn remet la base à zéro entre deux tests. Voici l’assemblage complet sur une petite API d’inscriptions à des événements.