Add AI meeting summaries

working-group/notes/2026/summary-2026-04-30.md

@@ -0,0 +1,67 @@
+# Meeting Summary for GraphQL-over-HTTP
+
+**NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated
+content may be inaccurate or misleading. Always check for accuracy. If in
+doubt, please consult the meeting recording at
+https://youtube.com/@GraphQLFoundation/playlists
+
+- Meeting start: 2026-04-30T18:31:41Z
+- Meeting end: 2026-04-30T20:09:07Z
+- Summary start: 2026-04-30T18:31:41Z
+- Summary end: 2026-04-30T20:09:05Z
+
+The HTTP Working Group discussed two major proposals for the GraphQL over HTTP specification: making the application GraphQL Response Plus JSON media type mandatory instead of optional, and supporting persisted documents by default. The group debated the benefits of requiring the new media type for better status code support versus the potential breaking changes it would create for existing servers and tools that rely on the current application JSON implementation. They also explored the idea of restructuring the specification to have separate chapters for each media type and discussed the challenges of implementing trusted documents as the default approach. The working group concluded that while the proposed changes have merit, particularly for long-term interoperability, they should be cautious about introducing breaking changes that could affect existing implementations, and decided to present these discussions to the main working group for further consideration.
+
+## Next Steps
+
+- Martin: Put the discussion about requiring the new media type (and breaking changes) on the agenda for the next main working group meeting for broader consensus.
+
+## Summary
+
+### HTTP Working Group Meeting Updates
+
+The HTTP Working Group meeting began with introductions from Benjie, Martin, and Pascal. The group discussed YouTube channel statistics, noting tens of views on technical discussions and the distinction between the GraphQL Foundation channel and GraphQL TV. The meeting's agenda focused on discussing two main topics: making application JSON type not supported by default in Appendix A, and whether to implement persisted documents by default. Benjie mentioned that grants are available for working group topics, and the meeting was being recorded for YouTube publication.
+
+### GraphQL Media Type Requirements Discussion
+
+Martin presented a pull request that proposes encouraging the use of the new GraphQL Response Plus JSON media type over the current application JSON by requiring new servers to support the new media type. Benjie questioned the change in wording for client requirements, suggesting that the previous text was more accurate as it required clients to indicate support for the new media type. Martin explained that the change was made to align with the server-side requirements for maximal compatibility, but Benjie argued that the original wording better reflected the intent of supporting both new and existing clients.
+
+### GraphQL Media Type Specification Changes
+
+Benjie and Martin discussed changes to the GraphQL specification regarding the inclusion of a new media type. Martin proposed removing certain language about legacy compatibility and requiring server support for the new media type. Benjie expressed concerns about the impact on existing non-compliant servers and questioned whether the change truly benefits anyone, particularly given GraphQL's tradition of maintaining backwards compatibility. The discussion centered on the trade-offs between enabling more flexible HTTP status codes and preserving compatibility with existing implementations.
+
+### GraphQL JSON Removal Discussion
+
+Martin and Benjie discussed the implications of removing application JSON from the GraphQL specification. Martin argued that this change would affect not just backend developers but everyone, including those using debugging tools, and emphasized the long-term benefits of a clean HTTP spec. Benjie acknowledged the debugging tool aspect and proposed making the new media type a recommended practice rather than required, allowing servers to choose implementation. The discussion highlighted concerns about breaking compatibility with existing tools and the additional effort required for tooling ecosystems to support multiple response types.
+
+### Protocol Restructuring and Persistent Documents
+
+Benjie proposed restructuring the specification to have separate chapters for different media types like JSON, JSONL, and multipart, rather than keeping them in an appendix. Martin expressed concerns about maintaining multiple protocols, particularly for WebSockets, arguing against having different versions. Benjie defended the value of multiple protocols, explaining that each has different trade-offs and advantages for specific use cases like incremental delivery and server-sent events. The discussion then shifted to the topic of persistent documents by default, with Benjie suggesting that GraphQL should be designed to only support persistent queries and trusted documents by default, rather than having these as optional features.
+
+### GraphQL Persistent Queries Implementation
+
+The team discussed implementing persistent queries in the GraphQL over HTTP specification, with Benjie proposing that servers should support ID and may support queries, while Pascal argued for a simpler requirement that servers must support ID or query or both. They debated the default behavior for production versus development environments, with Benjie suggesting that 95% of GraphQL servers should only support trusted documents in production. The discussion touched on the need for standardizing trusted document management and service capabilities to help clients automatically configure based on server capabilities.
+
+### GraphQL Capabilities Endpoint Proposal
+
+Benjie proposed adding a capabilities endpoint at /graphql/capabilities to allow discovery of server features beyond what GraphQL introspection provides. Pascal initially expressed concerns about allowing additional queries, but agreed that a dedicated endpoint approach was more sensible than allowing special introspection queries. Benjie also suggested making trusted documents the default in a future breaking change, arguing this would address significant issues in the GraphQL space related to query complexity and security.
+
+### Persistent Queries in Transport Specification
+
+Pascal expressed concerns about including persistent queries in the transport specification, arguing it should be handled at a higher level rather than as part of the transport mechanism itself. Benjie defended the inclusion, explaining that trusted documents (including persistent queries) involve complex integration challenges with build pipelines and client extraction processes, and suggested allowing both ID queries and persistent queries as options. Martin proposed adding a provision allowing alternative methods to retrieve documents if persistent queries aren't immediately adopted by everyone.
+
+### GraphQL File Format Standardization Discussion
+
+Benjie and Pascal discussed challenges with GraphQL file format and deployment across different platforms. They explored the idea of standardizing a protocol for handling GraphQL documents, suggesting support for multiple file storage methods including HTTP, Git, and Dropbox. Pascal raised concerns about managing multiple files for different platforms (mobile, web, TV, watch), while Benjie proposed using a key-based interchange format like KJSONL to handle multiple documents efficiently. The discussion focused on finding a unified approach to improve interoperability while allowing flexibility in implementation methods.
+
+### GraphQL Trusted Document Specification Discussion
+
+Benjie and Pascal discussed the inclusion of trusted document functionality in the GraphQL over HTTP specification. They agreed that while the capabilities endpoint could be part of the specification, the actual implementation details for trusted documents should be defined elsewhere. Pascal suggested using a standard /graphql/schema.graphql endpoint to address issue 300, and Benjie proposed making this a standard endpoint in the specification. They debated the security implications of different approaches, with Pascal favoring disallowing introspection fields over allowing non-persist operations, while Benjie expressed concerns about security through obscurity.
+
+### GraphQL Specification Breaking Change Discussion
+
+The team discussed whether to implement a breaking change to the GraphQL over HTTP specification regarding HTTP status codes. Benjie argued against making a breaking change, concerned it would retroactively label compliant implementations as non-compliant, particularly affecting legacy clients and documentation. Martin countered that these implementations were never compliant due to lack of a formal specification, and that new servers would continue supporting legacy clients for an extended period. The discussion highlighted the tension between moving forward with a formal specification and maintaining backward compatibility with existing implementations.
+
+### GraphQL Breaking Change Discussion
+
+Benjie and Martin discussed the potential risks and benefits of implementing a breaking change to GraphQL specifications, particularly regarding the use of application/json media type. Benjie expressed concerns about the impact on existing, unmaintained modules and the lack of data on potential breaks, arguing that the value of the change does not justify the risks. Martin suggested that while the cost of breaking changes varies, the long-term benefits might outweigh short-term inconveniences. They agreed to present the topic to the main working group for further discussion and consensus.