Accueil

Dans l’article précédent, nous avons vu comment Dapr simplifie l’invocation de service via HTTP. Mais Dapr supporte aussi nativement gRPC, à la fois entre les sidecars et entre votre application et son sidecar. gRPC apporte des avantages significatifs : sérialisation binaire (Protobuf), contrats fortement typés, streaming, et de meilleures performances. Dans cet article, on met en place un exemple complet : un service gRPC invoqué via Dapr, et un client qui l’appelle.

L’invocation de service (Service Invocation) est l’un des building blocks fondamentaux de Dapr. Il permet à un service d’appeler un autre service par son app-id, sans connaître son adresse IP ni son port, avec découverte automatique, load balancing, retry, chiffrement mTLS et traçabilité intégrés. En .NET, le SDK Dapr et HttpClient offrent plusieurs façons d’exploiter ce mécanisme.

Dapr (Distributed Application Runtime) est un runtime open source, porté par Microsoft et incubé à la CNCF, qui simplifie le développement d’applications distribuées (microservices, applications cloud-native). Il fournit un ensemble de building blocks — invocation de services, gestion d’état, pub/sub, bindings, secrets, etc. — accessibles via des API HTTP ou gRPC, quel que soit le langage ou le framework utilisé. L’objectif : permettre aux développeurs de se concentrer sur la logique métier, sans se noyer dans la plomberie de l’infrastructure.

En production, les appels réseau échouent : timeouts, erreurs 503, connexions refusées. Plutôt que de laisser ces erreurs transitoires remonter jusqu’à l’utilisateur, Polly permet de définir des stratégies de résilience — retry, circuit breaker, timeout, fallback — de manière déclarative. Depuis .NET 8, Polly v8 et Microsoft.Extensions.Http.Resilience s’intègrent nativement dans l’écosystème .NET.

La programmation asynchrone avec async/await est au cœur du développement .NET moderne. Elle permet de libérer des threads pendant les opérations d’entrée/sortie (réseau, fichiers, base de données) au lieu de les bloquer. Mais derrière cette syntaxe simple se cachent une machine à états, un SynchronizationContext, et de nombreux pièges. Cet article détaille le fonctionnement réel d’async/await, de la théorie aux bonnes pratiques.

LINQ rend le code expressif et concis, mais il est aussi facile de tomber dans des pièges qui dégradent les performances, provoquent des bugs subtils ou rendent le code difficile à maintenir. Cet article recense les bonnes pratiques à adopter et les erreurs les plus courantes à éviter quand on utilise LINQ au quotidien.

Quand on écrit .Where(x => x.IsActive), la syntaxe est identique que l’on travaille sur une List<T> ou sur un DbSet<T> Entity Framework. Pourtant le comportement est radicalement différent : d’un côté le filtre s’exécute en mémoire, de l’autre il est traduit en SQL. Comprendre cette dualité IEnumerable<T> / IQueryable<T> est essentiel pour éviter les problèmes de performance et les bugs subtils.

LINQ semble magique quand on l’utilise, mais sous le capot, ce sont des méthodes d’extension, des itérateurs (yield return) et des delegates qui font tout le travail. La meilleure façon de comprendre LINQ en profondeur est de recoder soi-même ses opérateurs principaux. Cet article propose une implémentation simplifiée de LINQ to Objects, opérateur par opérateur.