<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=471300) </details> <!--IssueSummary end--> MR: Pending ## Description The Web IDE Backend/Rails code does not follow standard patterns for the backend, e.g. Service Classes in a service layer. It could and should. See https://docs.gitlab.com/ee/development/reusing_abstractions.html#service-classes With https://gitlab.com/gitlab-org/gitlab/-/merge_requests/157999+, there is also availability of the ROP pattern for Settings, which could be more extensively used in settings, and applied elsewhere if appropriate. E.g. some logic in `lib/web_ide/extensions_marketplace.rb` could be moved down into the ROP settings chain as additional steps, and the return interface could be standardized around service layer and `ServiceResponse`, like the Remote Dev Workspaces domain does. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/remote_development/README.md#layered-architecture ## Acceptance Criteria TODO: Fill out (required) - [ ] [Describe what must be achieved to complete this issue.] - [ ] [Describe another requirement needed to complete this issue.] - [ ] [Add additional acceptance criteria as needed.] ## Technical Requirements TODO: Fill out or delete (optional) [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete (optional) [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete (optional) [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete (optional) [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->