Refactor Discussions REST API resources to use GraphQL internally
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
The goal is to convert the Discussions REST API endpoints to use GraphQL API internally to actually perform the function. This is part of our effort to use GraphQL everywhere (&1366)
The discussions API spans across several components, involves several actions:
-
Snippets -
Get single discussion item -
Create new thread -
Add note to existing thread -
Modify existing thread note -
Delete an issue note
-
-
Issues -
Get single discussion item -
Create new thread -
Add note to existing thread -
Modify existing thread note -
Delete an issue note
-
-
Epics -
Get single discussion item -
Create new thread -
Add note to existing thread -
Modify existing thread note -
Delete an issue note
-
-
Merge requests -
Get single discussion item -
Create new thread -
Add note to existing thread -
Modify existing thread note -
Delete an issue note
-
-
Commits
We should be able to gain some reuse, but at the very least each component will need the proper types added to their graphql queries.
In addition, not all the components have been implemented completely or at all, for example Snippets. So brand new queries will have to be created.
We can start tackling them one by one. Chances are these will spawn additional issues, for example handling sort parameters for an object. I don't think we're going to be able implement a "day per issue" as there are too many things still missing.
A good place to start would be for Issues, as I believe that's the most advanced at the moment.
Improvements
- Refactor https://docs.gitlab.com/ee/api/discussions.html to use GraphQL internally.
Risks
-
Security - GraphQL endpoints we create become immediately public. This means not only does the security of the API need to be maintained, but the security of the new graphql query needs to be solid. One should mostly follow from the other, but it needs to be kept in mind.
-
It is not necessarily a one-to-one mapping between a REST API and it's graphql implementation.
-
Performance - it's unclear whether performance will be affected or not. Some benchmarking should be performed if possible
Involved components
- Snippets
- Issues
- Epics
- Merge requests
- Commits
Optional: Intended side effects
- Each API endpoint should be completely implemented before considering it done