Filtrage et montée en charge des abonnements
Allez au-delà des abonnements de base : transmettez à chaque client uniquement les événements qui l’intéressent grâce au filtrage côté serveur, puis mettez les abonnements à l’échelle sur plusieurs instances Spring Boot.
Filtrage et montée en charge des abonnements est une leçon GraphQL APIs with Spring Boot gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage GraphQL APIs with Spring Boot, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours GraphQL APIs with Spring Boot comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Not Every Client Wants Everything
A naive subscription pushes every event to every subscriber. But a user watching order #42 does not care about order #99.
Filtering ensures each subscriber only receives the events relevant to them.
Subscription Arguments
Subscriptions can take arguments just like queries. A client passes the ID it cares about, and the server uses it to filter the stream.
type Subscription {
orderUpdated(orderId: ID!): Order
}Reactive Streams Recap
Spring for GraphQL represents a subscription as a Reactor Flux, an asynchronous stream of items. Filtering is just stream operations applied to that Flux.
Filtering with filter()
Apply .filter() to the publisher so only matching events flow to the subscriber.
@SubscriptionMapping
public Flux<Order> orderUpdated(@Argument String orderId) {
return orderPublisher.flux()
.filter(o -> o.getId().equals(orderId));
}A Shared Event Sink
Use a Reactor Sinks.Many as a hub. Your service emits events into it, and every subscription builds a filtered view of its stream.
private final Sinks.Many<Order> sink =
Sinks.many().multicast().onBackpressureBuffer();Emitting Events
When your business logic changes an order, push it into the sink so all matching subscribers are notified.
public void updateOrder(Order order) {
repository.save(order);
sink.tryEmitNext(order);
}The Scaling Problem
An in-memory sink only knows about events on its own JVM. With multiple Spring Boot instances behind a load balancer, an event emitted on instance A never reaches subscribers connected to instance B.
External Pub/Sub to the Rescue
Route events through an external broker like Redis Pub/Sub or Kafka. Every instance publishes to and subscribes from the broker, so all instances see all events.
Bridging Redis to a Flux
Subscribe to a Redis channel and feed incoming messages into the same Flux your GraphQL subscription exposes, unifying local and remote events.
redisTemplate.listenToChannel("orders")
.map(msg -> deserialize(msg.getMessage()))
.subscribe(sink::tryEmitNext);Backpressure and Cleanup
Slow clients can fall behind. Use a bounded buffer or drop strategy, and ensure resources are released when a client disconnects so memory does not leak.
Sinks.many().multicast().onBackpressureBuffer(1024, false);Best Practices
Keep subscriptions efficient:
- Filter on the server, never push everything
- Use an external broker to scale across instances
- Handle backpressure for slow consumers
- Clean up on disconnect to avoid leaks
Quick Check
Test your subscription scaling knowledge.
Recap
You scaled real-time subscriptions:
- Filter streams with
.filter()using subscription arguments - Use a
Sinks.Manyhub to broadcast events - Route through Redis or Kafka to scale across instances
- Manage backpressure and clean up on disconnect
Filtered, distributed subscriptions deliver the right data at scale.
Questions Fréquemment Posées
La leçon « Filtrage et montée en charge des abonnements » est-elle gratuite ?
Oui — le texte complet de « Filtrage et montée en charge des abonnements » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours GraphQL APIs with Spring Boot, passe à CoddyKit PRO. Le cours GraphQL APIs with Spring Boot comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Filtrage et montée en charge des abonnements » ?
Allez au-delà des abonnements de base : transmettez à chaque client uniquement les événements qui l’intéressent grâce au filtrage côté serveur, puis mettez les abonnements à l’échelle sur plusieurs i… Tu pratiques GraphQL APIs with Spring Boot avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer GraphQL APIs with Spring Boot ?
Aucune expérience préalable n'est requise. GraphQL APIs with Spring Boot sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Filtrage et montée en charge des abonnements » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon GraphQL APIs with Spring Boot ?
Oui. Chaque leçon GraphQL APIs with Spring Boot inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Comprendre les abonnements GraphQL
- Implémenter les mises à jour en temps réel
- Intégrer WebSockets à Spring
- Filtrage et montée en charge des abonnements