Brett Walker authored 5 years ago and Mayra Cabrera committed 5 years ago

- Due to https://github.com/exAspArk/batch-loader/pull/32,
we  changed BatchLoader.for into BatchLoader::GraphQL.for
- since our results are wrapped in a BatchLoader::GraphQL,
calling `sync` during authorization is required to get real object
- `graphql` now has it's own authorization system.  Our
`authorized?` method conflicted and required renaming

Brett Walker authored 5 years ago and Mayra Cabrera committed 5 years ago

The `GraphQL::Function` has been deprecated in
favor of resolvers.

Since the `GraphQL::ID_TYPE` usages should represent globally unique
ids, this changes some fields for which this is not the case into
strings.

The `ID_TYPE` is a specialised, so this change should be backwards
compatible.

https://graphql-ruby.org/type_definitions/scalars.html

We can query namespaces, and nested projects.

Projects now exposes statistics

and allow passing of child_complexity to the
'resolver_complexity' metho

Jan Provaznik authored 5 years ago and Ash McKenzie committed 5 years ago

If a field is a resolver, its complexity is automatically
increased. By default we add extra points for sort and search
arguments (which will be common for various resolvers).

For specific resolvers we add field-specific complexity, e.g.
for Issues complexity is increased if we filter issues by `labelName`
(because then SQL query is more complex). We may want to tune these
values in future depending on real-life results.

Complexity is also dependent on the number of loaded nodes, but only
if we don't search by specific ID(s). Also added complexity is limited
(by default only twice more than child complexity) - the reason is
that although it's more complex to process more items, the complexity
increase is not linear (there is not so much difference between loading
10, 20 or 100 records from DB).

This ports the changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10462/
to CE

Add new query for Groups, with new
GroupType and NamespaceType

Signed-off-by: Rémy Coutable <remy@rymai.me>

And fix the tests so that it won't run into circular paths.

This suggests possibly related issues when the user types a title.

This uses GraphQL to allow the frontend to request the exact
data that is requires. We also get free caching through the Vue Apollo
plugin.

With this we can include the ability to import .graphql files in JS
and Vue files.
Also we now have the Vue test utils library to make testing
Vue components easier.

Closes #22071

By specifying `key`, we get a different lazy batch loader for each
repository, which means that accessing a lazy object from one repository
will only result in that repository's objects being fetched, not those
of other repositories, saving us some unnecessary Gitaly lookups.

Partially addresses #47424.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

This adds Keyset pagination to GraphQL lists. PoC for that is
pipelines on merge requests and projects.

When paginating a list, the base-64 encoded id of the ordering
field (in most cases the primary key) can be passed in the `before` or
`after` GraphQL argument.

This allows the user to get a single MR nested in a GraphQL project
query.

Since we need the full path and the iid anyway, this makes more sense
than having a root query that needs the full path as well.

This was overridden in the fields where this resolver was used. So
this change is purely cosmetic.

- All definitions have been replaced by classes:
  http://graphql-ruby.org/schema/class_based_api.html
- Authorization & Presentation have been refactored to work in the
  class based system
- Loaders have been replaced by resolvers
- Times are now coersed as ISO 8601