Filtering on abstract types

[damikun]

Feature request:

It can be nice if new Filter API provides option to filter Interfaces or Unions by __typename..

Unions implements some interface and Filtering generate filters from props in this interface.. (out of gql type). Idea is to add there option for filter by type and provide string as name for it as filter input...

1. __typename filter - filter based on __typeame (baseobject type in c# checked by "is" )
2. smartunionresolver - resolver that takes array of dataloaders implementing equal interface and can generate filters and based on that include dataloader to be called or not.. so yo can call resolve(loader1, loader2 .. loaderN) from query you will have options to say exclude_type1...

It can be build in or require to call .AddTypeFilter()..

Currently
You needed to write special middleware or custom resolver for that... this can be in case of connections more difficult or you need to add Type field to your base object and get it from there.

Just example of current what you need to do.. in case you have 20 types it can get more ugly and there is possible way to add filtering based on typename or create smart resolver that take array of dataloaders and generate filters and call them conditionally..

 descriptor.Field(e => e.Assigned)
                .Argument("issues_not", e => e.Type<BooleanType>())
                .Argument("jobs_not", e => e.Type<BooleanType>())
                .Resolver(async (IResolverContext ctx) => {

                    List<Task> tasklist = new List<Task>();

                    IEnumerable<IAssigned> result = new ConcurrentBag<IAssigned>();

                    var issues_not = ctx.Argument<bool>("issues_not");
                    var jobs_not = ctx.Argument<bool>("jobs_not");

                    // This is working example but can be as generic smart resolver that take array of loaders and generates filters and conditionally call them.. At end it will concat results..

                    if (!issues_not) {
                        tasklist.Add(
                           ctx.DataLoader<UserAssignedIssueGroupLoader>()
                            .LoadAsync(ctx.Parent<GQL_User>().ID, default).ContinueWith(async e => result = result.Concat((await e)))
                        );
                    }

                    if (!jobs_not) {
                        tasklist.Add(
                            ctx.DataLoader<UserAssignedJobsGroupLoader>()
                            .LoadAsync(ctx.Parent<GQL_User>().ID, default).ContinueWith(async e => result = result.Concat((await e)))
                        );
                    }

                    await Task.WhenAll(tasklist);

                    return result;
                })
                .UsePaging<AsssignedTypeUnion>()
   ....
    ....

Idea:

Idea is to just specify typefilter and HC will generated this in case of interface for you... Is easy way it will just compare type with inputfilter type of string.

In case of __typename:

item(where:{type:"gql_tets_type"}){    // i call it "type" to, because not sure of using __typename (it is kind of reserverd)
   ....
}

In case of smartunionresolver

.ResolveUnion<IInterfaceType, UnionType>( dataloader1, dataloader2 ... dataloadern)  // Auto generation of filters and call loader conditionaly.. alll dataloader base object must implement some common interfaces... 

Advantages: Easy to filter types in unions..
Disadvantages: __typename can differs from base type, sometimes it is better to put it in resolver to avoid filtering after...

• easiest idea: just provide __typename filter as string and check if interface is of that type... (in case of IQueriable EF shoud be ok with "is IInterface" too)
• advanced idea: be able to resolve union types and based on this adds filter type options (is_not_Type1, is_not_Type2... )..

Problems with advanced:

• Filter are generated from base objects not from graphql objects so i see problem how to get all unions data for it...
• Possible inconsistency in Graphql typename and objectTypeName..

[damikun]

So small example whats the idea for unionresolvers (include filters)... This is not for UseSelection.. This can help you to implement Union loader

Current model can work without filters.. You can specify as much loaders as you wanna and run them without writing custom resolver for unions.. You can reuse loaders that you already have.. This is example that include some commented parts for filters that are not implemented...

This is example don`t check types of dataloader and use GetType() to get it in run-time.. To be Type-safe it is necessary to get type from data-loader base class.. what is bit not easy..

        public static IObjectFieldDescriptor ResolveUnion<T,U>(
            this IObjectFieldDescriptor descriptor,
             Func<IResolverContext, long> parentid,
             Func<IResolverContext, List<IDataLoader>> dataloadersfunc) where U :  UnionType<T>{

            if (descriptor is null) {
                throw new ArgumentNullException(nameof(descriptor));
            }

            if (dataloadersfunc is null) {
                throw new ArgumentNullException(nameof(dataloadersfunc));
            }

            // List<IDataLoader> dataloaders = dataloadersfunc(context);  // need to access context in some way in this place before resolver...

            // foreach (IDataLoader loader in dataloaders) {
            //     // Need to take all types from union and register arguments hire...
                descriptor.Argument("some way how to get unions types", e => e.Type<BooleanType>())  // just example
            // }

            descriptor.Resolver(async (IResolverContext ctx) => {

                List<IDataLoader> dataloaders = dataloadersfunc(ctx);

                long parent_id = parentid(ctx);

                List<Task> tasklist = new List<Task>();

                IEnumerable<T> result = new ConcurrentBag<T>();

                foreach (IDataLoader loader in dataloaders) {

                  // bool is_enabled = ctx.Argument<bool>(
                    // "Get dataloader Tobject in some way and try find it in arguments,,
                  //  );

                  // if (!is_enabled) {   // This is check if filter should include dataloader call

                    tasklist.Add(
                    loader.LoadAsync(parent_id, default).ContinueWith(async e => result = result.Concat((
                            (T[])(e.GetType().GetProperty(nameof(Task<object>.Result)).GetValue(e))
                        )))
                    );

                  //  }
                }

                await Task.WhenAll(tasklist);

                return result;
            });

            return descriptor;
        }

Than from code you can do this:

 descriptor.Field(e => e.Assigned)
                .ResolveUnion<IInterfaceType, UnionType>(
                     e => e.Parent<GQL_User>().ID,
                     e => new List<IDataLoader>() {
                     e.DataLoader<UserAssignedIssueGroupLoader>(),  // Loader1 
                     e.DataLoader<UserAssignedJobsGroupLoader>()}) // Loader 2

Currently im using only generic version of union resolver and i have separate mid. for filtering as you can see filter part is just commented out... The goal is connect UnionResolver with filters..

[PascalSenn]

so we have two options here at the moment.
The first one is to work around the issues with the fact that we are dealing with unions by properties:

input FooBarInputType {
   foo: FooFilterInputType
   bar: BarFilterInputType
}

This approach would also allow to specify different filter cases for foo and bar

Second option is to wait for the input union spec
graphql/graphql-spec#733

I guess it makes sense to wait in any case to see if how ever this turns out could be helpful for us

[damikun]

so we have two options here at the moment.
The first one is to work around the issues with the fact that we are dealing with unions by properties:

input FooBarInputType {
   foo: FooFilterInputType
   bar: BarFilterInputType
}

This approach would also allow to specify different filter cases for foo and bar

Second option is to wait for the input union spec
graphql/graphql-spec#733

I guess it makes sense to wait in any case to see if how ever this turns out could be helpful for us

Cool that they are working on spc. for this... that make more sense to wait for now and use only custom workaround until something will be published...