Add AI meeting summaries

notes/2025/summary-2025-08-07.md

@@ -0,0 +1,86 @@
+# 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-08-07T17:28:55Z
+- Meeting end: 2025-08-07T19:31:23Z
+- Summary start: 2025-08-07T17:31:25Z
+- Summary end: 2025-08-07T19:31:19Z
+
+The team reviewed progress on the composite schema specification implementation and discussed potential conference presentations about Federation's edge cases and performance optimization techniques. They explored various solutions for handling slow fields in GraphQL queries, including query splitting, parallel execution, and a new defer-based approach for improving performance. The conversation ended with discussions about GraphQL telemetry specifications, OpenTelemetry conventions, and plans for future conference presentations and technical improvements.
+
+## Next Steps
+
+- Mark: Implement the "dots get schema coordinate method" or "dot coordinate" attribute on object nodes as a follow-up to the schema coordinates PR.
+- Benjie and Lee: Continue polishing the spec for the upcoming release candidate to be presented at GraphQLConf.
+- TSC members: Review and validate the spec after the polishing phase is complete.
+- Mark: Prepare his talk for the GraphQL conference about hacking the query planner for parallel requests, while mentioning composite schema as a better future solution.
+- Pascal: Set up a call with Mark next week to discuss composite schema topics.
+- Pascal: Send Mark an invitation to the federated Slack workspace.
+- Mark: Connect with Pascal and Michael via Slack for further discussion on composite schema spec.
+- Michael: Implement the defer-based query planning approach in their query planner before the conference.
+- Michael: Investigate whether the lookup concept in the composite schema specification addresses the first problem Mark identified.
+- Mark: Confirm how lookup can solve the second problem posted in the discourse.
+- Team: Document the pure function requirement for lookups in the specification.
+- Pascal and Michael: Consider including cost analysis in query planning for the composite schema specification.
+- Michael: Evaluate whether the lookup concept in the composite schema specification needs clearer documentation regarding pure function guarantees.
+- Composite Schema team: Consider adding an appendix to the specification for directives that could help with query planning optimization.
+- Team: Explore implementing internal defer mechanism for query execution to optimize handling of slow fields.
+- Michael: Further develop the query planning strategy that automatically defers non-requirement fields.
+- Team: Investigate how to signal to the query planner when deferred behavior is desired.
+- Team: Consider updating gateway implementation to support defer between gateway and subgraphs.
+- Stephen: Evaluate requirements for re-architecting gateway implementation to support defer functionality.
+- Mark: Continue thinking about complex edge cases for the defer-based solution and potentially craft more examples.
+- Mark: Continue exploring query planning optimization strategies for composite schema to address the slow field parallelization issue.
+- Team: Evaluate the feasibility of implementing the defer capability between gateway and subgraphs within the upcoming timeframe.
+- Michael: Invite Mark to the Slack channel using his provided email addresses.
+- Mark: Check with IT admins about setting up Slack Connect.
+- Pascal: Submit the Open Telemetry specification proposal PR with GraphQL field coordinates.
+- Pascal: Add data loader batching to the Open Telemetry specification proposal.
+- Stephen: Prepare his panel and talk for the upcoming conference.
+- Mark and Pascal: Discuss appropriate messaging about composite schemas at the conference.
+
+## Summary
+
+### Composite Schema Implementation Progress
+
+The team discussed the implementation progress of the composite schema specification, with Pascal noting that while the specification remains a work in progress, the implementation is advancing well, particularly with Hot Chocolate, which is expected to be ready by the upcoming conference. Mark expressed interest in giving a talk about Federation's edge cases and how the composite schema specification could address them, leading to a discussion about connecting Mark to the relevant Slack workspace for further collaboration. The team also mentioned that while the specification aims to reach a draft state by the conference, this might not be feasible due to other preparation demands.
+
+### GraphQL Release and Schema Updates
+
+The meeting began with Pascal discussing the timing of a release, noting that releasing on a Thursday allows for assessment of issues by Monday. Mark mentioned the development of "Apollo GraphQL Intelligence," which Pascal praised as a clever branding move. The group then focused on schema coordinates, with Mark explaining recent changes to reduce the scope and simplify the implementation. Michael inquired about nullability, and Martin suggested that "capabilities" could be the new "nullability." The conversation ended with Michael taking over as host, introducing himself and the other participants, and outlining the agenda items for the meeting.
+
+### Schema Coordinates Implementation Changes
+
+The team discussed changes to the schema coordinates implementation, where Lee suggested reducing scope by defining schema coordinates with its own grammar and separate parser class. Mark confirmed these changes were accepted and relatively minor, though there was some bikeshedding about using full stops instead of hashtags. The team also noted that while the parser implementation had some overlap with the main GraphQL parser, it was decided to keep it integrated rather than creating a completely separate parser, as this would maintain consistency with the existing implementation and avoid potential syntax conflicts.
+
+### July Spec Cut Status Update
+
+The team discussed the status of the July spec cut, which is complete and in the polishing phase with Benjie and Lee working on editorial changes. They clarified that schema coordinates are not part of the current stack, and the TSC has 45 days for validation after the release candidate. Michael expressed a preference for doing one spec cut per year, focusing on technical improvements rather than new features. The conversation concluded with a lighthearted discussion about swimming in Amsterdam's canals, with Pascal warning about the potential dangers of open water swimming.
+
+### GraphQL Query Performance Optimization
+
+The team discussed a performance issue related to GraphQL queries involving slow fields, where Federation was making queries slower by introducing a cascading effect. Mark presented a solution he developed internally, which involves hacking the query planner by splitting the schema and sharding it to allow parallel fetching of slow fields. The group explored the possibility of adding built-in primitives or directives in the composite schema specification to facilitate such parallel processing, while Michael suggested leaving implementation details to implementers and adding relevant information to the compatibility page.
+
+### GraphQL Lookup Behavior Clarification
+
+The team discussed the behavior of lookups in GraphQL, particularly focusing on internal and public lookups. They clarified that internal lookups can contribute data to objects without being entry points, while public lookups can serve as entry points. Michael and Pascal explained that lookups can be executed in parallel when they are not entry points, but must run sequentially when they are. Mark raised a concern about potential issues with executing resolvers twice for optimization, but Pascal assured that lookups are designed to be pure functions with no randomness. The team also touched on the difference between lookups and public fields on query types, emphasizing that lookups provide a guarantee of consistent behavior.
+
+### Federated Query Optimization Strategies
+
+The team discussed query planning strategies for handling slow fields in a federated system. They explored options like splitting queries, using parallel execution, and implementing a declarative approach to signal the query planner. Mark explained the current limitations and inefficiencies of the system, while Michael suggested using a threshold-based approach to optimize query performance. The group also considered using the "defer" directive to handle slow fields efficiently. Pascal emphasized the importance of fetching identities in one request to optimize performance.
+
+### Query Defer Feature Implementation
+
+The team discussed a new approach to query execution using the defer feature, where the gateway would automatically defer non-essential parts of a query to improve performance. Michael proposed splitting queries into required immediate data and deferred data, with the gateway handling the execution and deduplication of these parts. The team agreed this could potentially improve overall performance by getting requirements early and executing subsequent requests more efficiently. They also discussed the need for the gateway and subgraphs to support this feature, with Stephen noting that their implementation would require re-architecting.
+
+### GraphQL Query Performance Optimization
+
+The team discussed a performance optimization technique for handling slow fields in GraphQL queries. Mark proposed a method where certain fields could be fetched separately and patched in later, similar to a "defer" mechanism. Michael and Pascal explained that this could be implemented in the query planner with minimal changes. They agreed that while this approach could improve performance in some cases, it might be too complex for general use. Mark mentioned he was planning to give a talk about this topic at an upcoming conference, and Michael offered to help implement a demo for the presentation. The team also discussed the potential for this technique to be used with GraphQL's built-in "defer" functionality, though they noted some challenges with implementing it in a federated graph.
+
+### GraphQL Telemetry Specification Discussion
+
+The group discussed GraphQL telemetry specifications and conventions, particularly focusing on how to handle query names and hashes in OpenTelemetry traces. Mark and Pascal debated the merits of using query hashes versus operation names, with Mark advocating for hashes as the more reliable identifier while acknowledging it's less human-friendly. Pascal shared that he had submitted a pull request for the OpenTelemetry specification and outlined plans to extend it with additional features including data loader batching and distributed GraphQL tracking. The group also discussed upcoming conference talks and agreed to continue discussions about error tracking and logging conventions in future meetings.