Contribution Topics

[michaelstaib]

Stitching

• Schema Transform / Merge
• MetaDB
• Execution Plan Integration
• Add ability to set TTL TimeSpan on redis query storage #3586
• OData Adapter for Stitching

Performance

• Execution Engine Optimization
• Validation Performance (Analyze: Dramatic performance improvements in large query validation in GraphQL-Java #4040)
• Parser Memory Improvements
• Possible memory leaks in stitching #2962

Quality Topics

• Missing Tests
• Fix Warnings
• Code Style Fixes
• Code Documentation
• XML documentation of most used APIs (Descriptors for example)
• Documenting one of the topics mentioned here

StrawberryShake

• Defer / Stream
• File Upload (Multipart request specification support for client-side #3312)
• Error: Enum values starting with underscore #4771
• Provide HttpStatusCode in IOperationResult #4759
• Be able to provide http and websocket client to strawberry shake #4754
• Error code from GraphQL is not correct in StrawberryShake #4596
• Strawberry Shake produces CS8604 #3985

Type System

• Improve XML to GraphQL Description (XML doc crawling should only use <para> for line breaks #3180, Smarter XML doc to schema doc translations #3730, see in XML comment causes invalid schema description #4070)
• schema-first

Spec Changes

• Introducing Merge Rules for Input Add rules for how circular references in Input Objects are handled #285

Data

• Bring back operation toggles on fields (descriptor.Field(x => x.Foo).AllowEqual().AllowNotEqual()) (HotChocolate.Data Filters and Sorting don't support explicit operations on a field level #3434)
• Introducing a source generator for Expressions. This will be used in a lot of different places, like filtering and sorting on computed fields and later also on projections. 
 This will also be used to prototype an easier way of adding custom filtering operation for the Expression Provider (that is used in e.g. EF-Core). Reference: Expressionify and EntityFrameworkCore.Projectables
• Make sure IQueryable implements IAsyncEnumerable before using ToListAsync #4018
• Add GetPagingArguments method to IResolverContext #3557

Spatial

• Sorting on spatial types (Sort by distance) (Sort by distance #1461)

Documentation

• Subscription Authentication (Authentication of Websocket connection #1732)
• Add documentation for IRequestExecutorResolver #3929

Database Specific Topics

MonogDb

• MongoDB geospatial data #3898
• MongoDB FindFluent TotalCount followup #3881

Postgres

• PostgreSQL JSONB Array not mapped correctly #4429

Elastic Search

• Join the discussion here :Elastic Search Integration #4883

[matt-psaltis]

Hey all coming at this from my current pain points mostly while I get across the larger vision :)

• Super graph partial loading / streaming / partitioning and sharding. All about being a good citizen in the cloud where memory isn't as cheap as the brochure says it is. :)
• flattened stitching everything in root. "just works" consistent collision renaming. Current collision algorithm is indeterminate. It's based on order of schema publishing from downstream.
• nested stitching more like gql namespacing I believe this is still controversial?
• existing renaming process doesn't rename enums when names collide.
• bcp: documentation mode take away all the dev centric components pure, unadulterated schema documentation
• ss: simplified multi clients per project
• ss / hc: wrapping async as sync (request/response)

[michaelstaib]

nested stitching more like gql namespacing I believe this is still controversial?

Yes, since it would entail something like nested mutations.

In any case, I think this is a bad idea since the idea with GraphQL is to have one consistent graph. With this we would essentially create a simple HTTP gateway that just does top-level routing.

[matt-psaltis]

Do we currently have any details / designs for the metadb?

[michaelstaib]

Not yet... The idea here is to have an in-memory read-only store that holds all the information for the gateway. Essentially we will read the supergraph and create from that the metadb. We do not need to have all type-information since we have an ISchema instance, but we need all additional information.

Shall we do a planning meeting on stitching to sketch things out or shall we do it async in a separate discussion?

[michaelstaib]

The topics are just starting points, from there we need to flash them out. I already have a prototype implementation of some things.

This is the very early prototyping:
https://github.com/ChilliCream/hotchocolate/tree/Gateway/src/HotChocolate/Stitching.Next

However, we will not build on that branch, it was more a proof of concept of certain concepts.