Defer and Stream Directives in GraphQL

Summary

Elena Matos and Rob Richard from FirstDibs discuss the 'defer' and 'stream' directives in GraphQL, which aim to improve application latency through incremental data delivery. They explain the motivation, current specification, and technical implementation of these directives, highlighting their benefits over traditional query splitting and pre-fetching techniques. The talk also covers best practices for implementing these features to enhance user experience without compromising performance.

Takeaways

• 🎯 Defer and Stream directives in GraphQL are designed to support incremental data delivery, reducing latency in applications.
• 🏬 First Dibs, an online marketplace for luxury items, is championing the adoption of these directives within the GraphQL specification.
• 💡 Defer allows the prioritization of essential data by postponing the delivery of non-essential data without splitting queries.
• 📜 Stream is used on list fields to incrementally deliver list items, enhancing the user experience by displaying critical content first.
• 🛠 Defer is only applicable to fragment spreads and allows flexibility in managing data delivery in large queries.
• ⚙️ The Stream directive requires fields of list type and uses an initial count argument to control the number of items returned in the initial response.
• 🔄 These directives do not require WebSockets or server-sent events; they work over regular HTTP connections using transfer encoding chunked.
• 📈 Implementing Defer and Stream can lead to performance improvements, especially in cases where not all data is immediately necessary.
• 🔧 For developers, async iterators and generators in JavaScript can be utilized to handle data streams effectively on both server and client sides.
• 🚀 While First Dibs has not yet deployed Defer and Stream in production, they are actively exploring its use to optimize performance in real-world scenarios.

Q & A

What is the primary focus of the talk by Elena Matos and Rob Richard from FirstDibs?

The talk primarily focuses on 'defer' and 'stream' directives in GraphQL and how they can be used to improve latency in applications through incremental delivery.

What are the proposed directives 'defer' and 'stream' in GraphQL intended to address?

The 'defer' and 'stream' directives are intended to support incremental delivery for stateless queries in GraphQL, addressing the issue of latency with large datasets and allowing clients to communicate the priority of requested data to GraphQL servers.

What is the main disadvantage of GraphQL's request and response model mentioned in the script?

The main disadvantage is that large datasets may suffer from latency, and not all requested data may be of equal importance, which can affect the application's performance.

What are the existing options for applications to prioritize certain data subsets and their trade-offs?

Existing options include query splitting and pre-fetching. Query splitting increases latency for lower-priority fields and can increase server costs due to multiple requests. Pre-fetching can improve or mask latencies but also increases server costs due to incorrect predictions.

How does the 'defer' directive work in the context of GraphQL?

The 'defer' directive can be specified on fragment spreads and allows GraphQL clients to communicate the priority of requested data, deferring the fetching of certain non-essential fields to improve the latency of essential fields without re-fetching data.

What is the 'stream' directive in GraphQL used for?

The 'stream' directive is used for fields that are of list type, allowing the server to return a specified number of list items as part of the initial response and stream the remaining items in subsequent payloads.

How does the response format differ when using 'defer' or 'stream' directives in GraphQL?

The response format includes multiple payloads when using 'defer' or 'stream' directives. The first payload is similar to a standard GraphQL response, but subsequent payloads include additional properties like 'label', 'path', and 'has next' to support incremental data delivery.

Why are WebSockets or Server-Sent Events not required for the 'defer' and 'stream' directives to work?

WebSockets and Server-Sent Events require a stateful server and complex infrastructure. The 'defer' and 'stream' directives use a normal HTTP connection with chunk transfer encoding and multi-part HTTP responses, which work with most existing HTTP infrastructure and are supported in older browsers.

What is the Fetch Multi-Part GraphQL library developed by FirstDibs, and what does it do?

Fetch Multi-Part GraphQL is a client library developed by FirstDibs to support reading chunked multi-part responses in any browser. It uses the Fetch API but falls back to the XML HTTP Request if Fetch is not supported, making it compatible with older browsers.

How does the implementation of 'defer' and 'stream' directives affect the predictability of GraphQL?

The implementation can affect predictability as the client specifies that it's okay for certain fields not to be returned immediately. This requires more work by GraphQL clients to handle the loading state and ensure a seamless user experience, especially when using type or code-generated types.

What is the current status of 'defer' and 'stream' directives at FirstDibs in terms of production usage?

As of the talk, FirstDibs is not using 'defer' and 'stream' directives in production but is actively working on features to add 'defer'. They are also considering the use of 'stream' but require further infrastructure changes for efficient implementation.