Flexible client side querying through @whereConstraints directive

[spawnia]

@whereConstraints

Add a dynamically client-controlled where constraint to a fields query.

Setup

This is an experimental feature and not included in Lighthouse by default.

First, enable the service provider:

'providers' => [
    \Nuwave\Lighthouse\Defer\DeferServiceProvider::class,
],

It depends upon mll-lab/graphql-php-scalars:

composer require mll-lab/graphql-php-scalars

Finally, add an enum type Operator to your schema. Depending on your
database, you may want to allow different internal values. This default
should work for most databases:

enum Operator {
    EQ @enum(value: "=")
    NEQ @enum(value: "!=")
    GT @enum(value: ">")
    GTE @enum(value: ">=")
    LT @enum(value: "<")
    LTE @enum(value: "<=")
    LIKE @enum(value: "LIKE")
    NOT_LIKE @enum(value: "NOT_LIKE")
}

Usage

The argument it is defined on may have any name but must be
of the input type WhereConstraints.

type Query {
    people(where: WhereConstraints @whereConstraints): [Person!]!
}

This is how you can use it to construct a complex query
that gets actors over age 37 who either have red hair or are at least 150cm.

{
  people(
    filter: {
      where: [
        {
          AND: [
            { column: "age", operator: GT value: 37 }
            { column: "type", value: "Actor" }
            {
              OR: [
                { column: "haircolour", value: "red" }
                { column: "height", operator: GTE, value: 150 }
              ]
            }
          ]
        }
      ]
    }
  ) {
    name
  }
}

The definition for the WhereConstraints input is automatically included
within your schema.

input WhereConstraints {
    column: String
    operator: String = EQ
    value: Mixed
    AND: [WhereConstraints!]
    OR: [WhereConstraints!]
    NOT: [WhereConstraints!]
}

scalar Mixed @scalar(class: "MLL\\GraphQLScalars\\Mixed")

[chrissm79]

@spawnia looks pretty interesting! Not able to test at the moment but should get to this soon. Will this suffer from the same exploit mentioned here since the column names are dynamic and controlled by the client? Might be nice to have the operators as Enums as well, not sure if those suffer the same fate as the columns or not.

[spawnia]

@chrissm79 good point, let's definitely fix the security issue before we merge this.

The article you linked was great, i think we can employ a similar security mechanism as in spatie/laravel-query-builder@3aa483b
We can just add a scalar ColumnName to make this constraint obvious to the client.

Having the operator as an Enum makes sense, but i am not too sure if we can define a generalized solution that works for all databases. Maybe we will have to leave that up to the user and make them add the enum Operator themselves, only providing suggestions or a default implementation.

[spawnia]

@chrissm79 fixed the security issue and made the user add an Operator enum themselves.

[chrissm79]

Nice job @spawnia!