- 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
- Move `calls_gitaly_check` to public
- Add instrumentation for flagging missing CallsGitaly declarations
- Wrap resolver proc in before-and-after Gitaly counts to get the net
Gitaly call count for the resolver.
This exposes all fields named `id` as GlobalIDs so they can be used
across our entire GraphQL implementation.
When the objects loaded are `ApplicationRecord`s. We'll use our
existing batchloading to find them. Otherwise, we'll fall back to the
default implementation of `GlobalID`: Calling the `.find` method on
the class.
Enabling GraphQL batch requests allows for multiple queries
to be sent in 1 request reducing the amount of requests
we send to the server.
Responses come come back in the same order as the queries were
provided.
It makes all Types::BaseField default to a complexity of 1.
Queries themselves now have limited complexity, scaled
to the type of user: no user, authenticated user, or an
admin user.
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.
- 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
By specifying a presenter for the object type, we can keep the logic
out of `GitlabSchema`.
The presenter gets initialized using the object being presented, and
the context (including the `current_user`).
