GraphQL Subscriptions : le troisième pilier de GraphQL
GraphQL a trois types d’opérations : Query (lecture), Mutation (écriture), et Subscription (temps réel). Les subscriptions permettent au serveur de pousser des données au client quand des événements surviennent. Chez Eve Media, nous utilisons les subscriptions pour les fonctionnalités temps réel.
Comment ça fonctionne
Le client s’abonne à un type d’événement. Quand l’événement se produit côté serveur, les données sont poussées au client. La connexion reste ouverte (généralement via WebSocket).
Syntaxe GraphQL
subscription OnMessageCreated { messageCreated { id content author { name } } }. Le client déclare exactement les champs qu’il veut recevoir, comme pour une query. Le typage GraphQL s’applique.
WebSocket et transports
Les subscriptions utilisent généralement WebSocket pour la connexion persistante. Le protocole graphql-ws est le standard moderne. Certaines implémentations supportent Server-Sent Events (SSE) en alternative.
Côté serveur
Apollo Server, Yoga, et autres serveurs GraphQL supportent les subscriptions. Vous définissez un resolver de subscription qui retourne un AsyncIterator. Le pub/sub connecte les mutations aux subscriptions.
Pub/Sub pattern
Quand une mutation crée un message, elle publie sur un topic. Les subscriptions écoutent ce topic. Redis ou un in-memory pub/sub distribue les événements. C’est le même pattern que l’event-driven architecture.
Côté client
Apollo Client, urql, et autres clients supportent les subscriptions. Le setup du WebSocket link est nécessaire. L’API useSubscription (React) est similaire à useQuery.
Cas d’usage
Notifications en temps réel. Chat et messagerie. Dashboards avec données live. Jeux multijoueurs. Collaboration en temps réel. Tout ce qui nécessite des updates push.
Filtrage des subscriptions
Vous pouvez filtrer par arguments : subscription OnMessage($roomId: ID!) { messageCreated(roomId: $roomId) {…} }. Le client ne reçoit que les messages de sa room.
Scaling
Scaler les subscriptions est complexe. Chaque connexion WebSocket consomme des ressources. Un pub/sub externe (Redis) permet le scaling horizontal. Les connexions doivent être gérées avec soin.
Alternatives
Pour des cas simples, le polling avec refetchInterval peut suffire. Server-Sent Events est plus simple que WebSocket pour le push unidirectionnel. Évaluez si la complexité des subscriptions est justifiée.
Conclusion
Les GraphQL Subscriptions apportent le temps réel dans le monde GraphQL avec le même typage et la même flexibilité. C’est puissant mais ajoute de la complexité. Utilisez-les quand le temps réel est vraiment nécessaire.
Chez Eve Media, nous implémentons GraphQL et ses subscriptions. Contactez-nous pour vos APIs temps réel.
