## Summary Use GraphQL + ApolloClient instead of REST + Vuex in the Static Site Editor. ## Benefits - Better suited for scenarios where network efficiency is important. For example, the Static Site Editor may implement a live updates feature. - Better suited for evolving APIs. - Requires less boilerplate to convert data returned by the server into proper domain objects for the frontend. ## Risks - We should adopt GraphQL as soon as possible because switching from Vuex + Rest to ApolloClient can consume a significant amount of resources as the feature set grows in the application. ## The plan Adopting GraphQL in the ~backend and ~frontend is an effort that could expand across several milestones. The main reason is that [GitLab GraphQL API](https://docs.gitlab.com/ee/api/graphql/reference/index.html#tree) does not provide the required queries and mutations to implement the Static Site Editor features. ### Phase 1: Replace Vuex with VueApollo in the Static Site Editor app Milestone: %"13.0" ~frontend #### Goal We aim to complete this phase in a single milestone %13.0. The goal is replacing Vuex with VueApollo by wrapping existing REST APIs on client-side resolvers for queries and mutations. To understand this strategy, read the following article about [wrapping REST APIs](https://dev.to/n_tepluhina/wrapping-rest-api-calls-with-apollo-client-do-it-yourself-approach-4i3p). You can also read [Apollo documentation about local state management](https://www.apollographql.com/docs/react/v3.0-beta/data/local-state/) for more information about implementing client-side resolvers. #### Tasks - [x] Setup ApolloClient. - [x] Create application local state type definition. - [x] Loading content’s source on the editor. - [x] Create client-side adapter for the files API. - [x] Create client-side resolver for title property. - [x] Use GraphQL API to load content in the main page. - [x] Editing content. - [x] Create setContent client-side mutation. - [x] Create `contentChanged` client-side state. - [x] Submitting changes. - [x] Create a client-side adapter for the create branch mutation. - [x] Create a client-side adapter for the create commit mutation. - [x] Create a client-side adapter for the create MR mutation. - [x] Create dismiss error mutation. ### Phase 2: Implement required queries and mutations in GitLab GraphQL API Milestones: %13.0 - 13.x ~backend #### Goal We will enhance GitLab GraphQL API by implementing the missing queries and mutations required by the Static Site Editor features. This phase runs in parallel with phase 1 but may expand to future milestones because the cost of implementing these APIs are medium to high. #### Tasks - [ ] Implement repository [files API](https://docs.gitlab.com/ee/api/repository_files.html) query https://gitlab.com/gitlab-org/gitlab/-/issues/216578 - [x] Implement create branch mutation gitlab#215617 - [x] Implement commit to branch mutation gitlab#215618 - [x] Implement create MR mutation gitlab#215619 ### Phase 3: Replace client-side REST resolvers with GitLab Milestones: %13.0 - 13.x ~frontend ~backend #### Goal After delivering a GraphQL API in the backend, we will replace the REST adapter implemented in the client with it. #### Tasks - [ ] Replace raw file REST API client-side resolver with GraphQL API - [ ] Replace create branch REST API client-side resolver with GraphQL API - [ ] Replace commit to a branch REST API client-side resolver with GraphQL API - [ ] Replace create Merge Request API client-side resolver with GraphQL API