Add optimized selects

[DDynamic]

• Added or updated tests
• Documented user facing changes
• Updated CHANGELOG.md

Resolves #1356

Changes
This MR optimizes queries generated by eloquent by only including the requested fields.

type Query {
  posts: [Post] @all
}

type Post {
  id: ID
  likes: Int
  title: String
  uppercaseTitle: String @select(fields: ["title"]) @method(name: "uppercaseTitle")
}

{
  posts {
    id
    uppercaseTitle
  }
}

The above schema definition and query cause SELECT * FROM posts to be executed. This MR adds adds in an opt-in configuration option to change this behavior to select only the fields required, SELECT id, title FROM posts. It adds a select directive to specify field dependencies, like in the case of uppercaseTitle.

@spawnia what do you think of this implementation idea? I could update the AllDirecrive to get the field selection with $resolveInfo, but I am not sure how to "look ahead" to field selection to see if there is a select directive present.

[spawnia]

First, I suggest to implement the trivial case without @select:

{
  posts {
    id
    title
  }
}

select id, title from posts;

Next, consider the implementation of https://github.com/nuwave/lighthouse/blob/master/src/Schema/Directives/CacheDirective.php, that should give you an idea how you can grab @select. You will have to combine the field selection from $resolveInfo with the type information from the schema. Tricky, but definitely doable.

The actual @select directive probably won't be much more than a marker and probably not contain much code.

Since many resolver directives can benefit from this optimization, it should be abstracted and made reusable. Maybe in a similar way as ArgumentSet::enhanceBuilder().

[spawnia]

Also, see #1253

[spawnia]

Suggested change

	columns: [String!]
	columns: [String!]!

This directive has no use without this argument.

[spawnia]

Since we are trying to optimize performance here: Those should all be const.

[spawnia]

Nice to see you pick up work on this branch again, this will be a big improvement when it lands. The code looks pretty good so far.

This feature seems like something that can have a lot of weird corner cases, so don't forget to add comprehensive tests.

[DDynamic]

Hey, @spawnia, thanks for checking in. I tried to get some work done on it this weekend, but I hit a wall with some edge cases and Eloquent limitations surrounding polymorphic relationships (example), so I decided to push what I had. The app that utilizes this only employs the all, paginate, and one-to-one and one-to-many relationship directives, so those use cases are working.

I'm not sure how many more hours I can put into this to address all of the edge cases. It would be an amazing edition though, nonetheless.

[spawnia]

A partial solution is better than no solution at all, if there are shortcomings we can document them and offer users the choice. Let's just make sure that whatever is implemented actually works.

[ghost]

I'm not sure, but if I need an accessor that is not in the table columns, we will get a "Column not found" SQL error.

Suggested change

	return array_unique($selectColumns);
	$allColumns = Schema::getColumnListing($model->getTable());
	return array_intersect($allColumns, array_unique($selectColumns));

[hassan-index]

@DDynamic
@spawnia
Lately, I've been working on a project where we're revaming our system and implementing GraphQL Lighthouse. One issue I've run into is that some of our tables have around 100 to 120 columns, which slows down the process even when I only need the ID and name. This is because I'm using the @find and @paginate directory, but behind the scenes, the MySQL query was selecting all columns from the "registrations" table.