<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=300399) </details> <!--IssueSummary end--> The following discussion from !52330 should be addressed: - [ ] @reprazent started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52330#note_496547752): (+1 comment) > This is a really cool use for GraphQL @georgekoltsov, I like the way it's done :smile:. I had one thought on the things @kassio already brought up in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52330?view=parallel#note_496545172. But as said, that's not for here. > > Another thing I was wondering: If we're importing from one group into another, on the same instance, I assume this is also possible? In those cases, we could theoretically avoid calling the API (and occupying a puma worker), but instead execute the query directly in the sidekiq-worker by calling [`GitlabSchema.execute`](https://gitlab.com/gitlab-org/gitlab/blob/e35cc79ac851d783ed402f74a670ade25243a7fe/app/controllers/graphql_controller.rb#L75) there. Is that something worth exploring?