**[DRI](https://about.gitlab.com/handbook/engineering/development/ops/release/planning/#epic-ownership): @shinya.maeda** ## Problem We have Environment page that users can access via "Deployments > Environments". This page is our main improvement area when it comes to [Environment Management and Continuous Deployment](https://about.gitlab.com/handbook/product/categories/#release-group), however, this page is also suffering by technical debts thus slowing our development speed. Currently, the page uses `environments.json` endpoint to fetch all of the visualization data from backend. When we extend the page, we need to add a new filed in the Environment Serializer. This is not just cumbersome for frontend, but also often causes performance issue ([Example](https://gitlab.com/gitlab-org/gitlab/-/issues/358780)) or production incident. We had to investigate the complex preload logic to patch them ([Example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86584)). This is not ideal from the code maintenance standpoint because it could be a fragile point that tends to be a bug or performance bottleneck. Instead of mitigating each N+1 issue as a spot fix, we should reconsider to rearchitect the data presentation process for frontend in a more simplified and maintenable way. ## Features are presented in the serializer and endpoint - Environments and Deployments Info - Deployment Approvals - [Multiple on_stop for an environment](https://gitlab.com/gitlab-org/gitlab/-/issues/22456) - And more ## Goals - We can easily extend the environment page without having a follow-up to fix performance issues. - We can easily understand the optimization code and fine-tune it if necessary. - Have a shared module/service that can be used anywhere, so that we don't need to optimize per endpoint. ## Key improvement - Replace the internal API (Environment Serializer) by GraphQL. Because: - This allows frontend to customize the query without touching backend code. - This GraphQL query can be used in any pages, not just Environment page. e.g. Showing environment info in pipeline page. - GraphQL framework supports type validation and batch loading. - GraphQL is the company-wide "go-to tool" instead of internal API. ### What kind of query is available? Add the following GraphQL queries: - Environment Lists - Description: It returns the high-level overview of project environments. - Usage example: [Environments Index Page](https://gitlab.com/gitlab-org/gitlab/-/environments) - Old Rest API endpoint: `environments.json` - Deployment Lists - Description: It returns the high-level overview of deployments of a specific environment. - Usage example: [Deployment Index page](https://gitlab.com/gitlab-org/gitlab/-/environments/1178942) (a.k.a. Environment Detail page) - Usage example: [Update GraphQL API to support environment detail page](https://gitlab.com/gitlab-org/gitlab/-/issues/367410) - Deployment Details - Description: It returns the details of a specific deployment. - Usage example: [Show tags related to deployed commit on Environment Page](https://gitlab.com/gitlab-org/gitlab/-/issues/15419) - Usage example: [Show tags related to deployed commit on Environment Detail Page](https://gitlab.com/gitlab-org/gitlab/-/issues/370400) - Usage example: [Deployment Issue (Deployment detail page)](https://gitlab.com/groups/gitlab-org/-/epics/7930) ### Query examples Environment Lists ``` { project(fullPath: "shinya.maeda/pipeline-playground") { environments { nodes { name state } } } } ``` Deployment Lists ``` { project(fullPath: "shinya.maeda/pipeline-playground") { environment(name: "production") { deployments { id ref sha } } } } ``` Deployment Details ``` { project(fullPath: "shinya.maeda/pipeline-playground") { environment(name: "production") { deployment(id: "123") { approvals related_tags } } } } ```