mappjzc opened a new issue, #4396: URL: https://github.com/apache/incubator-devlake/issues/4396
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and found no similar feature requirement. ### Use case ## Why Currently, in order to list all available scope for users to pick during configuration process, the config-ui has to fetch data from Data Source API via proxy BE API. This approach poses a couple of problems: 1. Frontend developers have to learn the API specification for all Data Sources. This is tedious and time-consuming. More importantly, we have only ONE full-time FE developer at this point. 3. Users might need to do the same thing if they chose to integrate Devlake rather than use it directly. 4. Even for a specific Data Source, the API version is likely to change over time, or we may opt for a lower API version to accommodate the user's needs. We don't want to modify BE and FE at the same time if it is unnecessary. ## What Design a set of APIs to isolate the FE from Data Source APIs, namely remote-scopes Scroll down to The design for the detail How it works Gitlab has the most complicated mechanism for us to fetch scopes for users to pick, so it was selected as the baseline of the design. It organizes groups and projects pretty much like the FileSystem: 1. Groups can have multiple groups and projects at the same time 2. There is an API to fetch groups of the root 3. There is another API to fetch projects of the root 5. There is another API to fetch groups under a group page by page 6. There is another API to fetch projects under group page by page So, the idea of the above design is to save FE/Advanced Users from this mess. We may store arbitrary information into the nextPageTokenas we see fit, and FE doesn't have to care about the detail, nor should it care. The idea for Gitlab is to concatenate the groups fetching and projects fetching API to one API remote-scopes: first, we load all groups and then projects . The trick is to store all the information in the nextPageToken such as isGroupsEnded page and others. The reason for the separated API search-remote-scopes to exist is that the Search API doesn't need to return group, only scopes, they work quite differently ### Description `GET /connections/:cid/remote-scopes` ```json { "children": [ { "type":"group", "parentId": null | groupId, "id": "", }, { "type":"scope", "parentId": null | groupId, "id": "", "data":{ .../plugins/{plugin}/connections/{connectionId}/scopes } } ], "nextPageToken": "bmRkdGYuY29tCg==" } ``` `GET /connections/:cid/search-remote-scopes` ```json [ { .../plugins/{plugin}/connections/{connectionId}/scopes } ] ``` ### Related issues _No response_ ### Are you willing to submit a PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
