Generating mutation models with ICollection instead of QueryBuilderParamter<ICollection<>>

[Isopolito]

Is there a way to configure the generation process so that it will not add the QueryBuilderParameter code?

So instead of this:

  [JsonConverter(typeof (QueryBuilderParameterConverter<ICollection<BorrowerInput>>))]
    public QueryBuilderParameter<ICollection<BorrowerInput>?>? Borrowers
    {
      get => (QueryBuilderParameter<ICollection<BorrowerInput>>) this._borrowers.Value;
      set
      {
        this._borrowers = new InputPropertyInfo()
        {
          Name = "borrowers",
          Value = (object) value
        };
      }
    }

It would simply generate this:

ICollection<BorrowerInput>?>? Borrowers

For more context:

The requirement in my organization is to provide consumers of our API a GraphQL api client that has c# models included and allows them to pass in a string query and a variable collection and get a strongly typed response.

for instance

        var query = "....query text here...."
        var response = await client.QueryGraph(query, variables);

I'm using this library to generate the models included in the api client, and graphql-client library for the actual query/mutation logic.

It works great, but one of our consumers is trying to map their models to the mutation models generated by this library and they're having issues because on their end they have a ICollection, but the mutation models are wrapped in the QueryBuilderParameter logic.

Hopefully that makes sense...

Thanks,

[Husqvik]

Interesting. I expected more issue if some one wants/needs to use System.Text.Json serializer as the input objects don't have support for it.

Is the issue related only to ICollection<>? Or it's something else. And even if only ICollection<> is still don't under what is the issue exactly. Implicit conversion?

[Isopolito]

So the use case is this:

We're generating a GraphQL Api client in our ci/cd pipeline for others in the org to use to consume our graph. I'm using this lib to generate the models.

The consumers of the api client in their code call the query logic in the api client and get back the models generated from this lib that are included in the api client. They use Automapper to map those models to their own domain's models. For queries, this works great because the generated query models look like this as an example:

  public class MilitaryIncome
  {
    public Decimal? Amount { get; set; }

    public string? Id { get; set; }

    public bool? IsTaxable { get; set; }

    public ICollection<MilitaryIncomeType>? MilitaryIncomeType { get; set; }

    public IncomePayPeriodType? MilitaryPayPeriod { get; set; }

    public Decimal? MonthlyAmount { get; set; }

    public bool? OmitFromTotals { get; set; }
  }

etc....
}

But when they try to map their models to the api client's mutation models, automapper blows up because the generated input models have this shape:

 public class MilitaryIncomeInput : IGraphQlInputObject
  {
    private InputPropertyInfo _amount;
    private InputPropertyInfo _id;
    private InputPropertyInfo _isTaxable;
    private InputPropertyInfo _militaryIncomeType;
    private InputPropertyInfo _militaryPayPeriod;
    private InputPropertyInfo _monthlyAmount;
    private InputPropertyInfo _omitFromTotals;

    [JsonConverter(typeof (QueryBuilderParameterConverter<Decimal?>))]
    public QueryBuilderParameter<Decimal?>? Amount
    {
      get => (QueryBuilderParameter<Decimal?>) this._amount.Value;
      set
      {
        this._amount = new InputPropertyInfo()
        {
          Name = "amount",
          Value = (object) value
        };
      }
    }

    [JsonConverter(typeof (QueryBuilderParameterConverter<string>))]
    public QueryBuilderParameter<string?>? Id
    {
      get => (QueryBuilderParameter<string>) this._id.Value;
      set
      {
        this._id = new InputPropertyInfo()
        {
          Name = "id",
          Value = (object) value
        };
      }
    }
.....

Does that make sense now?

[Isopolito]

I'm trying to come up with some automapper extension methods that will handle this mapping that can be included in the api client. Then consumer code could just use these extension methods for mapping and problem solved.

But really the cleanest solution would be to have query/mutation models that are simple POCOs and don't have any of the QueryBuilderParameter logic included, since we don't need it for our use case and it's causing these automapper issues.

I was digging through the docs and the tests in the repo to see if this is configurable--nothing jumped out at me though.

UPDATE:

I might have come up with a simple workaround. I will test it out and post back here. If it works I'll add some details in case other people in the future have this issue.

You have a lot more experience with GraphQL model generation than me, so I'm still curious on what your thoughts are though either way 😁

[Husqvik]

I'm not against adding the option you requested. Indeed there are many trivial cases where simple POCO is more than enough. The QueryBuilderParameter wrapping is there for binding variables. So it's possible to have a GraphQL query builder instance with parameters and then the same instance can be used over and over because the parameter is bound as $parameter. And the implicit conversion is there to be able to also use a literal. Using pure POCOs makes parameter binding impossible but as you mentioned for many use cases that's perfectly fine. Also in case some one has to use System.Text.Json, POCO will work, current implementation will not because there is no System.Text.Json converter to handle the QueryBuilderParameter wrapping.

[Isopolito]

That would be amazing because the workaround that I mentioned failed. I wasn't able to get those automapping extensions working either, so I'm kind of stuck.

[Isopolito]

Do you have a rough estimate on when this feature would be ready? I'm deciding if I need to start coming up with a work around or just wait for the enhancement

[Husqvik]

This is my pet project and I have regular job apart of it. I usually fix things during weekends.

[Isopolito]

I totally get that and your work is much appreciated 🙌 , I was just asking because if it was going to be weeks or months I would start implementing a post process step that would transform the mutation models into POCOs. Then swap out that temp solution with the new version of this when it's ready

[Husqvik]

Hi. I've been playing around with the idea. It's very simple to generate input objects without the parameter wrappings but they still aren't perfect POCOs due to internal specific input object handling.

So the class looks like this:

public partial class Collision3 : IGraphQlInputObject
{
    public string? Collision { get; set; }

    public string? Collision2 { get; set; }

    public string? CollisionInput { get; set; }

    public string? CollisionInputObject { get; set; }

    public string? CollisionDataRecord { get; set; }

    public string? CollisionRecord { get; set; }

    IEnumerable<InputPropertyInfo> IGraphQlInputObject.GetPropertyValues()
    {
        if (Collision != null) yield return new() { Name = "collision", Value = Collision };
        if (Collision2 != null) yield return new() { Name = "collision2", Value = Collision2 };
        if (CollisionInput != null) yield return new() { Name = "collisionInput", Value = CollisionInput };
        if (CollisionInputObject != null) yield return new() { Name = "collisionInputObject", Value = CollisionInputObject };
        if (CollisionDataRecord != null) yield return new() { Name = "collisionDataRecord", Value = CollisionDataRecord };
        if (CollisionRecord != null) yield return new() { Name = "collisionRecord", Value = CollisionRecord };
    }
}

but I think this could be ok because the interface implementation is explicit and invisible when working with class. One issue here is that it's impossible to distinguish default null from explicit null. In this implementation nulls will be ignored and not generated in the input object. Which may be a problem if something should be nullified by sending explicit null. There are ways to achieve that using other extension points. But if the intention is to use POCOs the schema should be designed the way that ignoring nulls is fine.

I think to add a new configuration option:

public enum InputObjectMode
{
    /// <summary>
    /// Supports GraphQL parameter references
    /// </summary>
    Rich,
    Poco
}

What do you think?

[Isopolito]

I love the configuration option--simple and explicit.

Seems like that class shape will work fine too. In the example there's just string?, but if the property is a ICollection<string> or int or whatever it would work the same I imagine? The fact that the class inherits from IGraphQlInputObject is fine, we can just ignore that.

As far as the nullability issue, that's something I just started looking into at work Fri. What I'm thinking of doing is borrowing the Optional concept from Apollo Kotlin.

I have the class already implemented with unit tests and a json serializer included and it's working well. It basically just provides a way to wrap a property so null and unspecified can be distinguished from each other. The implicit operators are implemented so it can be used naturally like regular primitives. When an Optional property is not set, it's considered Unspecified. When a property needs to be explicitly set to null, it's done like this:

mutationInput.FooBar = Optional<string>.Null

The json serializer ensures that the Unspecified properties are left out of the request payload when using the graphql-dotnet/graphql-client

I built a dotnet tool that leverages your framework to do the heavy lifting for model generation. There's a post processing step at the end that applies some transformations needed for our organization's use case. I'm going to add some logic there to wrap nullable properties with this Option class.

I'll be proofing all of this out early next week.

[Husqvik]

the QueryBuilderParameter supplies the same effect as Optional, it's also one of the reasons I implemented it in the first place. Since with the new option the property is as simple as { get; set; } I will try to provide an extension point so it can be customized the same way as normal data objects when POCO option is enabled.

[Isopolito]

That would be amazing thank you