|
| 1 | +# Meeting Summary for Working Group Meeting |
| 2 | + |
| 3 | +**NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated |
| 4 | +content may be inaccurate or misleading. Always check for accuracy. If in |
| 5 | +doubt, please consult the meeting recording at |
| 6 | +https://youtube.com/@GraphQLFoundation/playlists |
| 7 | + |
| 8 | +- Meeting start: 2026-03-19T17:31:12Z |
| 9 | +- Meeting end: 2026-03-19T19:09:08Z |
| 10 | +- Summary start: 2026-03-19T17:31:12Z |
| 11 | +- Summary end: 2026-03-19T19:06:45Z |
| 12 | + |
| 13 | +The meeting focused on reviewing Rob's pull request for incremental delivery specifications and discussing several GraphQL-related topics. Benjie provided feedback on the pull request, suggesting minor wording changes and clarifications, particularly around terminology and grammar. The group also discussed Mark's proposal for creating schema design guidelines and best practices documentation for GraphQL.org, with Benjie advising on how to present these as opinionated recommendations rather than mandatory standards. Additionally, Mark raised the topic of using more efficient binary formats like Argo for GraphQL responses, particularly for service-to-service communication, which Benjie suggested bringing to the GraphQL over HTTP working group for further discussion. The conversation ended with updates on closing some older issues and clarifications about the licensing for GAPS (GraphQL specification components). |
| 14 | + |
| 15 | +## Next Steps |
| 16 | + |
| 17 | +- Rob: Address Benjie's feedback on PR1203 (including typos, wording, and technical clarifications) and update the pull request within 24 hours. |
| 18 | +- Benjie: Review the updated PR1203, ideally by Thursday, to complete the review and potentially allow progress to the next part of the spec. |
| 19 | +- Mark: Update the schema guidelines GitHub issue to reflect the discussion about presenting guidelines as opinions, not requirements, and continue adding stubs for potential best practices. |
| 20 | +- Mark: Consider how to bucket and classify schema guidelines (e.g., for web services vs. other use cases) and update the issue/plan accordingly. |
| 21 | +- Martin: Add the schema guidelines documentation project to the call for project blog post for potential grant funding. |
| 22 | +- Mark: Take the topic of alternative GraphQL response encodings (e.g., Argo, CBOR) to the GraphQL over HTTP working group for further discussion. |
| 23 | +- Martin: Close the schema coordinate issue on GraphQL spec (as confirmed by Mark). |
| 24 | +- Martin: Propose closing the client control nullability operator issue (867) as RFCX (rejected), after confirming with Alex Riley, and update the issue status accordingly. |
| 25 | +- Benjie: Add RFC 0 tag to the disable error propagation issue and update as appropriate after discussion with Alex Riley. |
| 26 | +- Benjie: Discuss with Jory about GAPS governance docs and clarify the license (Open Web Foundation Agreement 1.0) for GAPS in the README. |
| 27 | + |
| 28 | +## Summary |
| 29 | + |
| 30 | +### GraphQL Pull Request Review Meeting |
| 31 | + |
| 32 | +The team discussed reviewing Rob's pull request (PR1203) for the GraphQL specification. Benjie and Martin agreed to take 30 minutes to review the PR, particularly focusing on the response section and naming suggestions, with Benjie noting he would need more than 25 minutes to thoroughly review it. The team planned to regroup in 22 minutes to continue the discussion after the review period. |
| 33 | + |
| 34 | +### Document Review Progress Update |
| 35 | + |
| 36 | +Benjie reported progress on reviewing the document, noting that the new words make it easier to read and that minor typos and grammatical improvements are needed in the appendix and Section 3. The team agreed to wait for Benjie to complete his review of Section 7 before proceeding, with a plan to regroup at 10 after. Mark raised a question about error handling for duplicate IDs in the incremental stream response, which Rob clarified was intended as a non-spec compliant requirement rather than a defined behavior. |
| 37 | + |
| 38 | +### Specification Document Feedback Review |
| 39 | + |
| 40 | +Benjie provided feedback on a specification document, suggesting minor corrections including changing "error" to "errors" and "completed result" to "incremental completion result." He identified a potential ambiguity in how overlapping deferred items use IDs and recommended adding a non-normative note to address this. Benjie also suggested reordering the presentation of keys for the incremental string result and adding clarification about when the "pending" key is required. Rob agreed to implement the changes within 24 hours and Benjie indicated he would review the updated version by Thursday. |
| 41 | + |
| 42 | +### Response Streams Implementation Discussion |
| 43 | + |
| 44 | +The team discussed the implementation and specification of response streams, with Martin expressing concerns about circular definitions but agreeing to move forward with the current approach. They reviewed the next steps for merging changes, including adding new validation rules and implementing the execution algorithm, which will be broken up into smaller groups for easier review. Benjie suggested pulling forward some base refactoring work, but Rob confirmed that most of the complex changes were already incorporated. The conversation concluded with a discussion about creating a compatibility website for different software versions, which Martin proposed could help with adoption. |
| 45 | + |
| 46 | +### GraphQL Schema Documentation Guidelines |
| 47 | + |
| 48 | +The team discussed documentation improvements for GraphQL schema guidelines. Mark presented a GitHub issue he started to collect best practices for GraphQL schemas, which Benjie praised as valuable but raised concerns about potentially marking existing schemas as non-compliant. Benjie emphasized that the Golden Path should be presented as optional best practices rather than mandatory requirements, allowing developers flexibility to use alternative approaches when justified. The discussion highlighted the need to clearly communicate that straying from guidelines is valid, especially for specialized use cases like Gatsby's asset loading. |
| 49 | + |
| 50 | +### GraphQL Best Practices Guidelines Discussion |
| 51 | + |
| 52 | +Mark and Benjie discussed creating guidelines for GraphQL best practices, agreeing to keep them informal and evolving over time rather than making them overly formal. They decided to document these guidelines on the GraphQL.org website using a pull request process similar to how other documentation is managed. Benjie suggested looking at ESLint's documentation patterns for inspiration and recommended considering how these guidelines could be used for tooling enforcement. They also discussed the potential for creating a separate dedicated website for schema design guidelines, with Mark agreeing to think more about the approach while being mindful of not overwhelming stakeholders with too many new initiatives simultaneously. |
| 53 | + |
| 54 | +### Schema Design Guides CFP Discussion |
| 55 | + |
| 56 | +The team discussed adding schema design guides to their call for project blog posts (CFP). They debated how to handle pre-approval of topics to avoid blocking potential contributors, with Benjie sharing experiences from previous grant recipients like Sarah and Mandy. The group agreed to include the schema design guides in the CFP, acknowledging that much of the content would involve gathering and reformulating existing guidance rather than creating new concepts from first principles. Mark also raised a separate topic about exploring more efficient ways of encoding responses in GraphQL, specifically mentioning Argon/CBOR and the potential for making this more official within the GraphQL community. |
| 57 | + |
| 58 | +### Argo Integration in GraphQL Standard |
| 59 | + |
| 60 | +Mark discussed the potential for integrating Argo, a binary GraphQL serialization format, into the GraphQL specification as a standard optimization. Benjie suggested presenting this topic to the GraphQL over HTTP working group and emphasized the importance of providing measurable performance benefits across languages. The group discussed the possibility of using grants to engage experts in existing Argo projects and ensuring compatibility with JSON serialization. Benjie also highlighted considerations around debuggability and the need for servers to support JSON alongside Argo. |
| 61 | + |
| 62 | +### GraphQL Issues and Licensing Discussion |
| 63 | + |
| 64 | +The team discussed closing several issues related to client controlability and error propagation in GraphQL. Benjie advised that the client control nullability operator issue should be marked as RFCX (rejected proposal) rather than closed, requiring Alex's agreement first. The disable error propagation issue was deemed appropriate to remain open as it serves as a temporary solution until the on error proposal is implemented. Mark inquired about the licensing for GAPS, and Benjie confirmed it would likely follow the same Open Web Foundation Agreement 1.0 license as the GraphQL specification. |
0 commit comments