Requêtes GraphQL, mutations, abonnements et guide RBAC

3. Abonnements – « Dites-moi dès que quelque chose se passe »

C’est là que GraphQL cesse d’être un bavardage poli et commence à être vraiment cool.

Une requête est « Quel est l’état actuel du rendez-vous du patient ? » Un abonnement consiste à « Envoyez-moi un SMS à la seconde où il change ». C’est la différence entre actualiser votre page de suivi de colis toutes les cinq minutes comme un homme des cavernes et recevoir une notification push au moment où votre colis quitte le dépôt.

Les abonnements sont terminés WebSocketpas du HTTP standard. Votre client ouvre une connexion et… attend. Pas de sondage, pas de piratage setInterval, pas de honte.

subscription OnAppointmentStatusChanged {
  appointmentStatusChanged(patientId: "patient-001") {
    id
    status
  }
}

Dans mon POC, dès qu’un médecin met à jour un rendez-vous de SCHEDULED à IN_PROGRESS, le tableau de bord du patient est mis à jour en direct, aucun bouton d’actualisation n’est requis. Le serveur publie un événement, l’abonnement l’attrape, l’interface utilisateur s’allume. Cela m’a vraiment semblé magique la première fois que je l’ai vu fonctionner, jusqu’à ce que cela ne fonctionne plus, à ce moment-là, cela ressemblait à une attaque personnelle. (Conseil de pro : vérifiez votre connexion WebSocket avant de supposer que l’univers vous déteste spécifiquement.)

Résumé accrocheur : Les requêtes demandent une fois. Les mutations agissent une fois. Les abonnements ne se taisent jamais, de la meilleure des manières.

4. Contrôle d’accès – « Tout le monde n’a pas la possibilité de tout voir »

Voici le rebondissement dont personne ne vous prévient : construire l’API est la partie la plus facile. Décider qui est autorisé à faire quoi C’est là que les choses deviennent épicées.

Dans un système de santé, ce n’est pas une option, c’est tout l’intérêt. Un patient ne devrait pas pouvoir consulter le dossier médical d’un autre patient. Une infirmière ne devrait pas pouvoir supprimer le compte d’un médecin. Et en aucun cas, personne, à l’exception des médecins et des administrateurs, ne devrait être autorisé à consulter des champs sensibles comme le SSN d’un patient.

Il s’agit du contrôle d’accès basé sur les rôles, ou RBAC, si vous aimez les acronymes à saveur légèrement bureaucratique.

L’idée est simple même si l’implémentation comporte des couches :

• Authentification répond « qui êtes-vous ? », généralement un jeton JWT que vous obtenez après vous être connecté.
• Autorisation répond « qu’est-ce que tu as le droit de faire, maintenant que je sais qui tu es ? »

En pratique, cela signifie que chaque opération GraphQL est vérifiée par rapport au rôle de l’utilisateur avant d’être autorisée à s’exécuter :

Rôle	Peut faire
PATIENT	Voir leur propre sur rendez-vous et ordonnances uniquement
INFIRMIÈRE	Afficher les patients, mettre à jour le statut du rendez-vous
MÉDECIN	Tout ce qui précède, plus la création de prescriptions
ADMINISTRATEUR	Tout, y compris les champs épicés comme le SSN

La partie vraiment amusante est niveau du terrain contrôle d’accès, pas seulement « pouvez-vous exécuter cette requête », mais « pouvez-vous voir ce champ spécifique dans la réponse ». Un patient qui interroge son propre dossier obtient SSN : nul même si le champ existe dans le schéma. Même requête, humain différent, réponse différente. C’est GraphQL qui rédige tranquillement un document juste devant vous, comme une agence gouvernementale polie.

La ligne à retenir : L’authentification est le videur qui vérifie votre identité. L’autorisation est le videur qui décide dans quelles pièces vous êtes autorisé une fois à l’intérieur. Ne confondez pas les deux, sinon vous passerez trois heures à déboguer un « bug » qui consiste en fait à sauter une étape.

Rassembler le tout (sans perdre la tête)

Voici le modèle mental qui a finalement fait cliquer pour moi :

• Schéma = le contrat. Quelles données existent, sous quelles formes elles se présentent.
• Requêtes = lire ces données.
• Mutations = changer ces données.
• Abonnements = être averti dès l’instant où les données changent, en direct.
• RBAC = le videur s’assure que tout le monde ne voit et ne touche que ce qu’il est censé faire.

Quatre notions. Un modèle mental. Aucun doctorat requis.

Ce qui m’a vraiment surpris en construisant tout cela, c’est à quel point tout cela est composable. Une fois votre schéma solide, les requêtes et les mutations s’écrivent pratiquement toutes seules. Les abonnements ne sont que des mutations avec un mégaphone. Et le RBAC, ce ne sont que… des règles, appliquées de manière cohérente, partout, sans exception, la même discipline que l’on attend d’un professeur strict mais juste.

Allez construire la chose

J’ai construit une version fonctionnelle complète de tout ce qui précède, patients, médecins, rendez-vous, ordonnances, abonnements en temps réel, contrôle d’accès complet basé sur les rôles, en utilisant Node.js, TypeScript, PostgreSQL et React. Pas d’ORM, pas de raccourcis, du SQL brut tout au long du processus, vous pouvez donc réellement voir ce qui se passe sous le capot au lieu de faire confiance à une boîte magique.

Lien de dépôt : https://github.com/ArzooJain-25/healthcare-graphql-poc

Clonez-le, exécutez-le, cassez-le, réparez-le. C’est véritablement le moyen le plus rapide d’apprendre ce genre de choses, non pas en lisant un autre article de blog (oui, même celui-ci), mais en regardant une requête échouer, en jurant doucement et en comprenant pourquoi.

GraphQL ne fait pas peur. C’est juste REST qui a finalement suivi une thérapie et a appris à communiquer clairement ses besoins.