ChilliCream / ChilliCream/graphql-platform
GraphQLNullTypeAttribute request
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 5.8k
- Forks
- 810
- Avg merge
- 15h 39m
- Merged PRs (30d)
- 98
Description
Product
Hot Chocolate
Is your feature request related to a problem?
With a nullable enabled solution I would like to have compile time enforcement on nullability without having error boundaries always tightly coupled with the nullability of my C# types.
In particular the issue I'm having is that I want my queries and mutations to be able to return a non-nullable type while still returning a 200 response if an exception is thrown.
e.g. given the query
public async Task<TheStuff> GetStuff(string stuffId) { ... }
the GQL schema generated is stuff(stuffId: String!): TheStuff! which results in a 500 response if the query throws an exception
The solution Iv'e come up with for now is to do
[GraphQLType(typeof(TheStuff))]
public async Task<TheStuff> GetStuff(string stuffId) { ... }
which results in the GQL schema stuff(stuffId: String!): TheStuff which returns a 200 if an exception is thrown.
However aside from this solution being awkward and unintuitive it's also imperfect because this code
[GraphQLType(typeof(List<Stuff>))]
public Task<List<Stuff>> GetStuffs(string stuffId) { ... }
results in the GQL schema stuffs(stuffId: String!): [TheStuff] but I would want it to be stuffs(stuffId: String!): [TheStuff!]
The solution you'd like
I think a simple solution to this problem would be create GraphQLNullTypeAttribute similar to the GraphQLNonNullTypeAttribute.
I understand that the intention of GraphQLNonNullTypeAttribute was likely to support solutions where null enforcement is not enabled but I think using my proposed GraphQLNullTypeAttribute in a nullable enables solution would provide a lot of flexibility so that the C# type and the GQL schemas could diverge where appropriate.
I could also see this being useful to control GQL error boundaries deeper in the GQL schema while maintaining compiler time enforcement on on the desired C# types.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the existing GraphQLNonNullTypeAttribute and the schema-generation path that maps C# nullability to GraphQL types. Check how nullable return values and list element types are represented, then add coverage for the requested scalar and list schemas and verify the resulting error-boundary behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, graphql
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100