Input conversion for variations of properties?

[jamesdh]

So I have the following query method...

@GraphQLQuery(name = "indicatedProviders")
public ExtendedConnection<IndicatedProvider> findBy(
        @GraphQLArgument(defaultValue = "{}") ProviderFilter where,
        @GraphQLArgument(defaultValue = "20") @Nullable Integer size,
        @GraphQLArgument(defaultValue = "0") @Nullable Long offset
)

...where ProviderFilter is simply a series of properties that we can filter on that largely match the IndicatedProvider, e.g...

public class ProviderFilter {
    public Long id;
    public String firstName;
    public String lastName;
    public String middleName;
    public Gender gender;
    // etc...
}

On the frontend, I'm giving Refine w/ MUI a try. While implementing a MUI DataGrid, the built-in filtering works by taking whatever property you wish to filter, and appending the filter operation type to it with a potential value, and responds with that as part of the where method argument. So the following example filters:

lastName equals "Doe"
firstName contains "John"
middleName starts with "C"

...becomes:

where: {
  lastName: "Doe",
  firstName_contains: "John",
  middleName_startswith: "C"
}

Which results in a potential explosion of argument types since there are 7 different operation types and each property can potentially have all 7.

What I want to do is given a set of property names, expose all those variations as part of the schema thus they appear as valid queries to any clients. But upon actually receiving the query I want to parse the response such that firstName_contains: "John" can be broken down into simply...

filter.firstName = "John"
filter.firstNameOperation = FilterOperationType.CONTAINS

Basically, I'm trying to avoid having to define every possible variation of every property in my ProviderFilter class, and instead parse and break down each argument into a simpler form. I've been poking around the code a bit looking at InputConverters but struggling to make sense of it since there are no docs and in the case of InputConverters, no tests demonstrating their usage.

[jamesdh]

On 2nd thought, this probably isn't worth bothering with. It makes more sense to fix this on the client side and thus avoiding this type of pain on every potentially filterable query method.