From 008d90313cd3a467addf324f3cc15b1c9357e9a7 Mon Sep 17 00:00:00 2001 From: Benjie Gillam Date: Thu, 30 Oct 2025 11:13:34 +0000 Subject: [PATCH] Add AI meeting summaries --- notes/2025/summary-2025-10-23.md | 49 ++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 notes/2025/summary-2025-10-23.md diff --git a/notes/2025/summary-2025-10-23.md b/notes/2025/summary-2025-10-23.md new file mode 100644 index 0000000..fa7b479 --- /dev/null +++ b/notes/2025/summary-2025-10-23.md @@ -0,0 +1,49 @@ +# Meeting Summary for Composite Schemas WG + +**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: 2025-10-23T15:59:46Z +- Meeting end: 2025-10-23T16:52:34Z +- Summary start: 2025-10-23T16:01:04Z +- Summary end: 2025-10-23T16:52:33Z + +The GraphQL working group discussed deprecation handling and directive merging, exploring alternative approaches to deprecation handling and confirming meeting video publication and membership agreements. The team examined directive ordering and precedence in their schema, particularly focusing on deprecated fields and tombstone directives, while also discussing issues with directive definitions in Apollo Federation and the need for a clear source of truth. The group explored ownership models and schema evolution, debated the behavior of executable and compose directives in composite schemas, and discussed a proposed change to the specification that would allow metadata on directives, with the team agreeing to further explore more explicit control over directive composition. + +## Next Steps + +- Michael to draft an RFC on directive composition with more explicit control over where directives appear . +- Michael to flesh out a proposal for directive merging that addresses both executable directives and type system directives. +- Team to consider whether to pursue directives on directives as a spec change. + +## Summary + +### GraphQL Deprecation and Directive Updates + +The GraphQL working group discussed deprecation handling and directive merging. Michael presented an internal discussion about how deprecations are currently implemented, noting that one team can unilaterally deprecate fields without coordination. The group agreed to explore alternative approaches to deprecation handling, particularly for shared types and fields. They also confirmed that meeting videos would be published to YouTube and agreed to the GraphQL spec membership agreements, participation guidelines, and code of conduct. + +### Schema Directive Precedence Discussion + +The team discussed the ordering and precedence of directives in their schema, particularly focusing on deprecated fields and tombstone directives. Michael and Stephen noted that their implementation follows a natural precedence based on type ownership, with a shared value type library that minimizes conflicts. While Stephen acknowledged that the current system sometimes produces surprising results with multiple directives, they haven't encountered significant problems with deprecated fields due to their strict enforcement and shared repository approach. + +### Apollo Federation Directive Conflicts + +The team discussed issues with directive definitions in Apollo Federation, particularly when dealing with shared libraries and multiple subgraphs. Michael explained that conflicts arise when different subgraphs can modify the same directive definitions, while Pascal noted that even without shareable directives, conflicts can occur between different subgraphs. Derek shared customer feedback about the need for a clear source of truth for directive definitions, especially in distributed systems, and suggested that the most recently updated version or the one with better documentation should take precedence. + +### Schema Evolution and Ownership Models + +The team discussed ownership models and schema evolution, with Michael noting difficulties in implementing a single boss-type system and suggesting influence over merging processes. They explored directive merging, distinguishing between executable and type system directives, with Michael observing that executable directives can be implicitly shared across subgraphs in Apollo but require explicit declaration in their system. Martijn suggested the need for more cascades, and Derek raised a question about schema composition that remained unresolved. + +### Composite Schema Directive Behavior + +Michael, Sachin, and Derek discussed the behavior of executable and compose directives in a composite schema. They clarified that executable directives do not require explicit declaration across subgraphs if they have matching definitions, while compose directives need to be linked and imported. Sachin explained that executable directives were established before the concept of compose directives, which was designed to address the need for metadata in supergraphs. The team debated whether to make the process of including directives more consistent, potentially reducing surprises when introducing new subgraphs. + +### Directives Metadata Change Discussion + +The team discussed a proposed change to the specification that would allow metadata on directives, which Michael described as a small change with a major impact on the ecosystem. Pascal compared it to the moon landing, emphasizing the significance of the change despite its small size. The team debated whether to proceed with this change, considering its potential effects on the parser and the possibility of implementing other features like directional enums. + +### Apollo Federation Directive Composition + +The team discussed the handling of directives in Apollo Federation, particularly focusing on compose directives and their metadata usage. They clarified that compose directives are only included in the supergraph schema, not the public API schema, and serve primarily as metadata for gateway plugins rather than being exposed to end users. Michael proposed an RFC to explore more explicit control over where directives should be composed, distinguishing between supergraph and API schema usage, though Derek noted potential complexity around merge rules for custom directives. The team agreed that while the current system works, there could be value in having more explicit control over directive composition, especially for authorization and semantic nullability use cases.