GraphQL setup: Basic Project and Merge request endpoint

What does this MR do?

This is based on the work done in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13601.

It removes some logic from the types, uses existing logic in presenters.

Other TODO:

• Add 'full stack' tests for each query with all fields?

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests added for this feature/bug
• Conform by the code review guidelines
  • Has been reviewed by a Backend maintainer
• Conform by the merge request performance guides
• Conform by the style guides
• If you have multiple commits, please combine them into a few logically organized commits by squashing them

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/34754

EE-Port in: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5969

changed the description

@DouweM The list of attributes in the description seems quite large. WDYT if we do this in steps:

MR 1: Setup

• Setup of the gems (by @nick.thomas)
• Authentication & Authorization (by @nick.thomas)
• Setup of helpers for presenters
• Helpers for query specs
• Basic attributes for the MR (not all nested types)

MR 2: All attributes (mentioned in the description here)

MR 3: Mutation for merge request

• Merge
• Rebase
• Approve
• ...

@reprazent Wow, that's a lot of attributes :) Splitting it up like that definitely makes sense. We may want to split up step 2 a bit more, even. I imagine it will take some time to settle on the best way to expose ability (can_) and link/path information in a sensible, reusable, consistent way so that we set a strong standard for GraphQL APIs going forward, for example, and something simple like adding commits_count ideally wouldn't be blocked by that conversation.

@DouweM I've already implemented some things to allow using presenters in the ObjectTypes. That already helps with a lot of attributes. I'll include that here.

---

@DouweM GitHub exposes the explorer for their graphql API.

Should we do something similar? They do clever things with authentication and so on, but I guess the simplest thing would be to just open up the GraphiQL endpoint we already have? And then iterate on that?

@reprazent Yeah, let's open up the endpoint, and address this separately. Initially, this API is not going to be complete enough for outside use anyway.

changed the description

marked the checklist item Add 'full stack' tests for each query with all fields? as completed

changed title from GraphQL endpoint that could be used for the merge request widget to GraphQL setup: Basic Project and Merge request endpoint

marked the checklist item Add 'full stack' tests for each query with all fields? as incomplete

marked the checklist item Add 'full stack' tests for each query with all fields? as completed

marked the checklist item Changelog entry added, if necessary as completed

marked the checklist item API support added as completed

marked the checklist item Tests added for this feature/bug as completed

added 290 commits

• 8d9e134e...4d674bd3 - 285 commits from branch master
• d5ef3bae - Add a minimal GraphQL API
• 815d30fb - Convert from GraphQL::Batch to BatchLoader
• 6eb957f5 - Add `present_using` to types
• 370c9306 - Handle exceptions outside the GraphQL schema
• 73c47dce - Initial setup GraphQL using graphql-ruby 1.8

Compare with previous version

marked the checklist item Documentation created/updated as completed

added 1 commit

• 43349010 - Initial setup GraphQL using graphql-ruby 1.8

Compare with previous version

mentioned in merge request !13601 (closed)

Continuing the discussion in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13601#note_37735154

Using batch-loader over graphql-batch because we already included that as a dependency.

I couldn't find a way to use promise-like chaining of loaders, other than calling .sync and continue with a real object. For now I think that's sufficient.

added 1 commit

• c9a4f48b - Initial setup GraphQL using graphql-ruby 1.8

Compare with previous version