ChilliCream / ChilliCream/graphql-platform

GraphQLNullTypeAttribute request

Open
#5,980 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

🌶️ hot chocolate Area: Type System
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.