Add AI meeting summaries

notes/2025/summary-2025-09-18.md

@@ -0,0 +1,62 @@
+# Meeting Summary for Working Group Meeting
+
+**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-09-18T17:29:37Z
+- Meeting end: 2025-09-18T19:23:02Z
+- Summary start: 2025-09-18T17:32:34Z
+- Summary end: 2025-09-18T19:19:58Z
+
+The meeting focused on discussing proposals for new GraphQL features, particularly around handling polymorphic types in lists and type filtering capabilities. The participants explored various technical approaches including directives, syntax modifications, and client-side implementations, while considering implementation challenges and user experience implications. They also discussed specific aspects like abstract type handling, pagination configurations, and connection information, ultimately deciding to gather more feedback before finalizing implementation approaches.
+
+## Next Steps
+
+- Mark: Continue developing the RFC for the "matches" directive to filter polymorphic types in GraphQL queries
+- Mark: Incorporate feedback from the discussion into the RFC proposal
+- Mark: Follow up with Lee regarding his syntax extension proposal for the same problem
+- Mark: Address edge cases in the match directive proposal
+- Mark: Clarify the validation rules for the "matches" directive, especially regarding how it determines what types to validate against
+- Mark: Explore the possibility of a syntax extension as an alternative solution
+- Mark: Consider how code generation tools might integrate with the proposed solution
+- Benjie: Provide additional feedback on the RFC as it develops
+- Benjie: Provide more detailed feedback on the full proposal after reading it completely
+- Team: Evaluate Relay's compiler approach for handling union type selections without requiring manual argument maintenance
+- Team: Consider solutions for clients without a compiler step that avoid duplicating union member declarations as enums
+- Lee: Provide insight on his syntax extension proposal that could solve the same problem
+
+## Summary
+
+### GraphQL Polymorphic Type Handling Proposal
+
+Mark presented a proposal for a new GraphQL directive to address the issue of handling polymorphic types in lists, particularly for server-driven UI scenarios. The directive, inspired by Relay's match directive, would allow clients to specify which types they want to receive from a union or interface, ensuring compatibility with both compiled and runtime environments. Benjie explained the technical challenges and the need for a solution that doesn't rely on selection sets, as it could lead to caching issues. The proposal includes a "supports" argument that would validate and filter the types returned by the server, providing a more efficient and user-friendly approach compared to existing solutions.
+
+### GraphQL Enums vs Strings Debate
+
+Benjie and Mark discussed the use of enums versus strings in the matches directive for GraphQL schemas. Benjie suggested allowing both enums and strings, with a validation rule ensuring that enum values match the type names exactly. They debated the need for strict validation against existing types versus allowing subsets or future types. Benjie proposed a simple enum solution with code generation to handle the rest, emphasizing that GraphQL should prioritize explicitness over DRY principles. They also discussed the implications of using interfaces and the need for a signal to code generators about possible types.
+
+### GraphQL Type Filtering Proposal
+
+Benjie and Mark discussed a proposal for a new GraphQL feature that would allow clients to specify which types they want to query. They agreed that this should be a client opt-in feature, rather than a schema requirement, due to potential breaking changes and caching complications. They explored different syntax options, including a special selection set or a new directive, and decided to keep the focus on type filtering rather than ordering. Mark agreed to leave ordering considerations out of scope for this discussion.
+
+### GraphQL Abstract Types Discussion
+
+Benjie and Mark discussed different approaches to handling abstract types in GraphQL queries. They explored three options: doing nothing in the spec, adding new syntax for concrete type selection, and implementing a schema directive with client-side enforcement. Benjie explained the pros and cons of each option, emphasizing that option two (new syntax) would be relatively minimal and ergonomic for users. Mark expressed concerns about the complexity of implementing new syntax, but Benjie assured that GraphQL.js could handle the necessary filtering and validation. They concluded that further evaluation of these options is needed, with a focus on balancing user experience and implementation challenges.
+
+### GraphQL Multiple Type Selection Discussion
+
+Benjie and Mark discussed two options for handling a new pattern in GraphQL queries that allows selecting multiple types within a single selection set. Option 1 involves creating a new client specification inspired by Relay's implementation, which Benjie supports and Mark considers already partially implemented. Option 2 involves modifying the GraphQL syntax to include a "match" syntax, with Benjie suggesting the use of a distinct symbol to avoid confusion with existing directives. They also discussed the possibility of creating a community-driven specification under the GraphQL organization, similar to the Scalars project, with Benjie expressing support for this approach.
+
+### GraphQL Syntax Feature Proposal
+
+Mark and Benjie discussed a proposal for a new GraphQL syntax feature that would allow for more flexible mode configurations. Benjie explained that while the feature could be implemented without changing the spec (Option 1), a custom syntax solution (Option 2) would be preferable in the long term. They agreed that Option 2 would require significant time and effort to get through the spec process, but could be worth pursuing if there is sufficient demand. Mark decided to wait for more feedback at the next working group meeting before deciding whether to focus on Option 1 or Option 2.
+
+### GraphQL Pagination Schema Design Challenges
+
+Benjie and Mark discussed the challenges of expressing pagination and connection information in a GraphQL schema, focusing on how to handle different selection sets for nodes and edges. They explored potential solutions, including using repeatable connections and separate fields for nodes and edges, drawing inspiration from existing APIs like Star Wars GraphQL. Mark acknowledged the complexity of this issue and suggested that inconsistent use cases might indicate a problem with schema design.
+
+### GraphQL Type Matching Implementation Discussion
+
+Mark and Benjie discussed the challenges of implementing a feature that allows clients to specify which types to include in a GraphQL query. They explored different options, including making connections an explicit part of the GraphQL spec and standardizing argument names for type matching. Benjie advocated for a client-side solution, where clients would handle the type matching using directives, rather than trying to implement it in the GraphQL specification itself. Mark agreed to further investigate the possibility of a client-side solution while also working on formalizing the current RFC into a user-facing specification.