Accueil

Accueillir un nouveau collaborateur, c’est créer sa fiche RH, attendre qu’il signe son contrat, ouvrir son compte, lui donner accès à une demi-douzaine d’applications, puis lui envoyer un questionnaire un mois après son arrivée. Un processus qui dure des jours, qui doit survivre aux redémarrages et savoir annuler ce qui a été fait si quelque chose échoue. Le building block Workflow de Dapr permet d’écrire ce processus comme du code C# séquentiel, rendu durable par le runtime. On voit ici les principes (déterminisme, replay), les patterns (chaînage, fan-out/fan-in, événements externes, timers, compensation) et la gestion des instances, avec Dapr 1.18 et le SDK .NET 1.18.

La plupart des API de Dapr (invocation de service, état, pub/sub…) sont sans état côté runtime : chaque appel est indépendant. Les Actors proposent un tout autre modèle de programmation : des milliers, voire des millions de petits objets avec état, identifiés par un ID, activés à la demande et qui traitent leurs messages un par un. On voit ici le modèle virtual actors à travers un parc de thermostats connectés, son implémentation avec Dapr.Actors (Dapr 1.18, SDK .NET 1.18), les timers et reminders, et les cas où ce modèle est un bon choix… ou pas.

Mettre une API ASP.NET Core dans un conteneur prend dix lignes de Dockerfile. Obtenir une image petite, rapide à construire, non-root et sans shell inutile demande un peu plus de méthode. Cet article passe en revue le Dockerfile multi-stage bien fait, le choix des images de base .NET 10 (dont les variantes chiseled), la publication sans Dockerfile avec dotnet publish /t:PublishContainer, puis l’exécution en conditions réelles : health checks, limites mémoire, scan de vulnérabilités et CI.

Introduit timidement en C# 7, le pattern matching s’est enrichi à chaque version jusqu’à devenir l’un des outils les plus expressifs du langage. Tests de type, comparaisons, décomposition d’objets, analyse de listes : on peut désormais exprimer en une seule switch expression des règles métier qui demandaient autrefois une cascade de if. Cet article passe en revue tous les patterns disponibles, l’exhaustivité vérifiée par le compilateur, deux exemples métier réalistes et les pièges classiques.

Une chaîne de connexion dans un appsettings.json, une clé d’API dans un YAML versionné : les secrets finissent toujours par fuiter quand on les traite comme de la configuration ordinaire. Le building block Secrets de Dapr expose une API unique pour lire des secrets, quel que soit le coffre sous-jacent (fichier local, variables d’environnement, Kubernetes, Azure Key Vault, HashiCorp Vault…), et permet aux composants eux-mêmes de référencer ces secrets. On voit ici l’API, son utilisation depuis .NET (Dapr 1.18, SDK .NET 1.18), l’intégration à IConfiguration et le contrôle d’accès, à travers un service de réservation de salles qui doit se connecter à sa base et à une API de paiement tierce.

Les bindings sont le building block de Dapr qui relie une application au monde extérieur : un déclencheur planifié, une file d’attente, un serveur SMTP, un stockage blob, une API HTTP tierce… Un input binding déclenche l’application quand un événement externe survient, un output binding lui permet d’agir sur un système externe, le tout sans embarquer le moindre SDK spécifique. On les illustre ici avec un service de traitement des factures fournisseurs, avec Dapr 1.18 et le SDK .NET 1.18.

Chaque requête qui arrive dans une application ASP.NET Core traverse une chaîne de middlewares avant d’atteindre un endpoint, puis la remonte en sens inverse avec la réponse. Authentification, gestion des erreurs, CORS, compression, fichiers statiques : tout est middleware. Comprendre ce pipeline, son ordre et ses pièges est indispensable dès qu’on dépasse le template par défaut.

Depuis .NET 6, ASP.NET Core propose deux façons d’écrire une API HTTP : les Controllers MVC, historiques et très outillés, et les Minimal APIs, plus légères et devenues le modèle mis en avant par les templates. Avec .NET 10, l’écart fonctionnel s’est presque refermé : validation intégrée, OpenAPI natif, filtres, groupes de routes. Cet article compare les deux approches sur le même endpoint, montre comment organiser proprement des Minimal APIs, et propose une grille de choix nuancée.