Investigate and design a REST-to-GraphQL API Bridge
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
From the decision made at the FY26Q1 Tech Summit "Rethink our approach to maintaining our APIs (REST + GraphQL)" session -- documented in https://docs.google.com/document/d/1VNB3ivS9aCJc-fck1TLP48pzFYRsEPASLijn9ufXctY/edit?tab=t.2fcx3kdhhtj#bookmark=id.djz9l4fdc97u
At present, GitLab's REST and GraphQL APIs are defined separately in Rails.
In some cases for new APIs introduced in future (and possibly reactively applied to existing APIs), it may be more efficient for us to build the REST API on a bridging adapter to the underlying GraphQL API.
Example
Take the case of #460668 for instance. At present, there is no WorkItems API in REST.
One approach to resolving this would be to develop a WorkItems REST API, but have it map down to a set of GraphQL queries underneath.
All authentication and authorization aspects would be passed to GraphQL, avoiding the need to reimplement them. REST GET and HEAD requests would map to queries and PUT, POST queries would be implemented as mutations.
Action
What is needed is a clear understanding of the advantages and disadvantages of this approach. If it is determined that it would be a good route forward, we would want a very easy-to-follow, declarative approach (aka, a paved path) which would be reused across multiple REST endpoints.
Some aspects which would need to be considered would be:
- Would this component become a nascent API gateway into the GitLab Application?
- Security concerns
- Scalability and efficiency of the gateway
- Monitoring, tracing, logging