Open rspeele opened 8 years ago
Note: the last option sounds hairy, but might actually be very simple, given that the contract of IExecContext
is to return instances of our own GraphQL value type. If we use an external library we'll be bringing in a lot of code to produce CLR types, only to reverse that work and go back to a dead simple AST-like DU in the IExecContext
implementation.
Any news on this? We would like to use Insomnia since it supports GraphQL query but the problem is that Insomnia always send the variables
even if it's empty.
This would be very nice to have. We are implementing GraphQL with a SQL backend and graphql-dotnet supports Variables but is very cumbersome to use when actually hooking up to a DB. GraphQL.Net makes that task way easier but the lack of support for Query Variables is a big downside. I can't get variables to work even with default values either as show on the GraphQL Learn Default Variables.
Would love to get an update on this.
Currently GraphQL.cs always uses
DefaultExecContext.Instance
.This context doesn't resolve any variable names. It screams and dies when a query contains variables. We should support passing variables to queries. The most common way is certainly by a JSON blob like
{ variableName1: value1, variableName2: value2 }
. Maybe XML is desirable too.At minimum, we should support letting users pass their own
IExecContext
in. Ideally, we should have some helpful standard implementations people can use.Some options:
IExecContext
implementations with those dependenciesIExecContext
implementation using our own JSON parser with FParsec