| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
58404 - add change log
58404 - add spec
58404 - add more spec to test depth 2
58404 - fix spec
58404 - fix rubocop
58404 - refactor the code by Bob's advice
58404 - revert changes of all_graphql_fields_for
58404 - change text only
58404 - fix rspec according to gitlab's standard
58404 - revert previous spec
58404 - fix rubocop
|
|
With this we only check abilities on the rendered edges of a GraphQL
connection instead of all the nodes in it.
|
|
|
|
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 is mainly the setup of mutations for GraphQL. Including
authorization and basic return type-structure.
|
|
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`).
|
|
|
|
|
