Subscription filtering in GraphQL - Step-by-Step Execution

Concept Flow - Subscription filtering

Client subscribes with filter

↓

Server receives subscription request

↓

Server applies filter criteria

↓

Events generated on server

↓

Filter checks each event

↓

Send event

↓

Client receives filtered events

The client subscribes with a filter; the server applies it to events and sends only matching events to the client.

Execution Sample

GraphQL

subscription onNewMessage($userId: ID!) {
  messageAdded(filter: {recipientId: $userId}) {
    id
    content
    senderId
  }
}

Client subscribes to new messages only for a specific user ID.

Execution Table

Step	Event Generated	Filter Condition (recipientId == userId)	Pass Filter?	Action	Client Receives
1	{id: 101, content: 'Hi', senderId: 'A', recipientId: 'U1'}	U1 == U1	Yes	Send event	{id: 101, content: 'Hi', senderId: 'A'}
2	{id: 102, content: 'Hello', senderId: 'B', recipientId: 'U2'}	U2 == U1	No	Ignore event	None
3	{id: 103, content: 'Hey', senderId: 'C', recipientId: 'U1'}	U1 == U1	Yes	Send event	{id: 103, content: 'Hey', senderId: 'C'}
4	{id: 104, content: 'Yo', senderId: 'D', recipientId: 'U3'}	U3 == U1	No	Ignore event	None
5	No more events	-	-	-	-

💡 No more events generated, subscription ends or waits for new events.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	Final
event	null	{id:101,...}	{id:102,...}	{id:103,...}	{id:104,...}	null
filterPass	null	true	false	true	false	null
clientReceived	[]	[{id:101,...}]	[{id:101,...}]	[{id:101,...},{id:103,...}]	[{id:101,...},{id:103,...}]	[{id:101,...},{id:103,...}]

Key Moments - 3 Insights

Why does the client not receive events where recipientId does not match userId?

Because the filter condition fails (see execution_table rows 2 and 4), so those events are ignored and not sent to the client.

What happens if no events match the filter?

The client receives no events (empty list), as shown in execution_table rows where filterPass is false and action is 'Ignore event'.

Does the server send all events to the client before filtering?

No, the server applies the filter first and only sends events that pass the filter, as shown in the 'Action' column.

Visual Quiz - 3 Questions

Look at the execution_table, what is the 'filterPass' value at Step 3?

A true

B false

C null

D undefined

💡 Hint

Check the 'Filter Condition' and 'Pass Filter?' columns at Step 3 in the execution_table.

At which step does the client receive the event with id 103?

A Step 2

B Step 3

C Step 4

D Step 1

💡 Hint

Look at the 'Client Receives' column for event id 103 in the execution_table.

If the filter condition changed to recipientId == 'U2', which step would send an event to the client?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Refer to the 'Event Generated' and 'Filter Condition' columns to see which event has recipientId 'U2'.

Concept Snapshot

Subscription filtering lets clients receive only events matching criteria.
Client sends filter with subscription.
Server checks each event against filter.
Only matching events are sent to client.
Non-matching events are ignored.
This saves bandwidth and processing.

Full Transcript

Subscription filtering in GraphQL means the client asks to get only certain events, like messages for a specific user. The server gets this request and checks every new event. If the event matches the filter, it sends it to the client. If not, it ignores it. This way, the client only gets relevant updates. For example, if the client wants messages where recipientId equals their userId, only those messages are sent. Events with other recipientIds are skipped. This filtering happens on the server before sending data, saving resources and making updates efficient.

Practice

1. What is the main purpose of subscription filtering in GraphQL subscriptions?

easy

A. To batch multiple queries into one request

B. To store data permanently in the database

C. To receive only relevant real-time updates based on specified conditions

D. To convert queries into mutations automatically

Solution

1. Step 1: Understand subscription filtering concept

   Subscription filtering allows clients to specify conditions so they only get updates they care about.

2. Step 2: Compare options with concept

   Only To receive only relevant real-time updates based on specified conditions describes receiving relevant real-time updates, which matches subscription filtering.

3. Final Answer:

   To receive only relevant real-time updates based on specified conditions -> Option C

4. Quick Check:

   Subscription filtering = relevant updates [OK]

Hint: Filtering means getting only updates you want [OK]

Common Mistakes:

• Confusing filtering with data storage
• Thinking filtering batches queries
• Assuming filtering changes query types

2. Which of the following is the correct syntax to add a filter argument to a GraphQL subscription named newMessages that filters by userId?

easy

A. subscription { newMessages(userId: "123") { id content } }

B. subscription { newMessages(filter: { userId: "123" }) { id content } }

C. subscription { newMessages(where: userId = "123") { id content } }

D. subscription { newMessages(user_id: "123") { id content } }

Solution

1. Step 1: Identify correct filter argument syntax

   GraphQL subscriptions commonly use a filter argument with an object specifying conditions.

2. Step 2: Match options to syntax

   subscription { newMessages(filter: { userId: "123" }) { id content } } uses filter: { userId: "123" }, which is the correct way to pass filter conditions.

3. Final Answer:

   subscription { newMessages(filter: { userId: "123" }) { id content } } -> Option B

4. Quick Check:

   Filter argument uses object syntax = subscription { newMessages(filter: { userId: "123" }) { id content } } [OK]

Hint: Use filter: { field: value } for subscription filters [OK]

Common Mistakes:

• Using direct argument instead of filter object
• Incorrect filter keyword like where
• Wrong field name casing or underscores

3. Given this subscription query:

subscription { newOrders(filter: { status: "SHIPPED" }) { id status } }

Which orders will the client receive updates for?

medium

A. All orders regardless of status

B. No orders, because filter syntax is invalid

C. Only orders with status "PENDING"

D. Only orders with status "SHIPPED"

Solution

1. Step 1: Analyze the filter condition

   The filter specifies status: "SHIPPED", so only orders with this status qualify.

2. Step 2: Determine which updates are sent

   The subscription sends updates only for orders matching the filter, so only "SHIPPED" orders.

3. Final Answer:

   Only orders with status "SHIPPED" -> Option D

4. Quick Check:

   Filter status = "SHIPPED" means only shipped orders [OK]

Hint: Filter limits updates to matching status only [OK]

Common Mistakes:

• Ignoring filter and expecting all updates
• Confusing status values
• Assuming filter syntax is wrong without checking

4. Consider this subscription query:

subscription { newComments(filter: { postId: 42 }) { id content } }

It returns no updates even when new comments are added to post 42. What is the likely issue?

medium

A. The filter argument is missing the correct type or schema support

B. Subscription queries cannot have filters

C. The filter field name should be post_id instead of postId

D. The subscription name newComments is invalid

Solution

1. Step 1: Check filter usage in subscription

   Filters require the schema to support filtering on the specified field and type.

2. Step 2: Identify why no updates appear

   If the schema does not support filtering by postId, the filter silently blocks updates.

3. Final Answer:

   The filter argument is missing the correct type or schema support -> Option A

4. Quick Check:

   Schema must support filter fields for updates [OK]

Hint: Check schema supports filter fields used [OK]

Common Mistakes:

• Assuming field name casing is always wrong
• Believing filters are not allowed in subscriptions
• Thinking subscription name causes no updates

5. You want to subscribe to real-time updates of tasks but only for tasks assigned to user ID 7 and with priority "HIGH". Which subscription filter is correct?

hard

A. subscription { tasks(filter: { assignedUserId: 7, priority: "HIGH" }) { id title } }

B. subscription { tasks(filter: { assignedUserId: "7", priority: HIGH }) { id title } }

C. subscription { tasks(filter: { assignedUser: 7, priority: "HIGH" }) { id title } }

D. subscription { tasks(filter: { userId: 7, priority: "HIGH" }) { id title } }

Solution

1. Step 1: Match filter fields to requirements

   The filter must use assignedUserId for user ID 7 and priority as "HIGH" string.

2. Step 2: Check option correctness

   subscription { tasks(filter: { assignedUserId: 7, priority: "HIGH" }) { id title } } correctly uses numeric 7 and string "HIGH" with proper field names.

3. Final Answer:

   subscription { tasks(filter: { assignedUserId: 7, priority: "HIGH" }) { id title } } -> Option A

4. Quick Check:

   Correct fields and types in filter = subscription { tasks(filter: { assignedUserId: 7, priority: "HIGH" }) { id title } } [OK]

Hint: Use exact field names and correct value types in filter [OK]

Common Mistakes:

• Using wrong field names like userId instead of assignedUserId
• Mixing string and number types incorrectly
• Omitting quotes around string values