Hi! What's the recommended way to deal with filter...

# graphql

[dave08]

Hi! What's the recommended way to deal with filtering by field in a search (like when using a React datatable)? Is there something in graphql-java or graphql-kotlin to simplify/standardize this?

[mbonnin]

I'm not super familiar with react but it looks like a client thing not related to the API ?

[dave08]

I would have thought that there is some kind of expansion of the query language to handle passing over filtering... in regular systems, they have different ways of searching each type of field. For strings, there's startsWith, contains, containsOneOf..., for dates, there's before, after, between... etc... it sounds like something that could be handled by some framework instead of each person re-inventing the wheel.

[dave08]

Like https://grandstack.io/docs/graphql-filtering/

[dave08]

Or https://dgraph.io/docs/graphql/queries/search-filtering/

[Dariusz Kuc]

Keep in mind that GraphQL does not imply a database so there is no built-in operations that you would see in SQL.

[Dariusz Kuc]

Libraries that expose databases using GraphQL like hasura or dgraph might provide some SQL like features but that is specific to those implementations.

[dave08]

Yeah, that's understandable.

But maybe there's something in Graphql-kotlin that can generate a re-usable set of query arguments?

[dave08]

Something like the way DataFetchingEnvironment or the context can be passed to `Query`s?

[dave08]

I guess creating a class like UserFilters and UserSorters, and passing them to the queries would be the solution, but the filter types for its fields would need to be copied manually in all projects and clutter the schema itself.

[Dariusz Kuc]

as you mentioned - you could reuse same input objects but you would have to explicitly specify it for each function

[Dariusz Kuc]

that being said schema should be explicit so IMHO having that extra hidden functionality (like those sort/filters) that is not defined in the schema is problematic

[dave08]

True. I was wondering if it would fit the bill of a custom type, or directive?

[dave08]

I'm a bit new to all this, so I don't really know how people implement this. And it seems like each backend has it's own additions...

[Dariusz Kuc]

i'd imagine that should be some custom type

[Dariusz Kuc]

e.g. consider something like Date -> how do you represent it in the graph?
• is it a formatted string? (or should there be multiple formats?)
• is it a long?
• do you deconstruct it to separate fields?

[Dariusz Kuc]

creating new function/resolver is always cheap -> it is backwards compatible change and clients have to opt-in to use it

[dave08]

You mean a new type, but a new scalar or directive would not be recommended?

[Dariusz Kuc]

in general i'd stay away from custom scalars as clients need to know how to parse them (recently there was added functionality to provide some additional info to the scalar definition)

[Dariusz Kuc]

so even if your server defines custom Date scalar that serializes it as X, all your clients have to know how to deserialize X into proper type (in general it defaults to String)

[Dariusz Kuc]

or even simpler example Java Long -> you cannot represent it as Javascript Number so it is a custom scalar

[Dariusz Kuc]

*there are some libs that attempt to define some common custom scalars

[dave08]

Thanks for the explanation 👌🏼!