Commit 8a6ccf22 authored by Mike Jang's avatar Mike Jang

Merge branch '233063-cablett-mutation-granularity' into 'master'

Add mutation granularity guidance

See merge request gitlab-org/gitlab!38558
parents 1e1242d6 c68c0e08
...@@ -827,10 +827,39 @@ mutation. ...@@ -827,10 +827,39 @@ mutation.
### Building Mutations ### Building Mutations
Mutations live in `app/graphql/mutations` ideally grouped per Mutations are stored in `app/graphql/mutations`, ideally grouped per
resources they are mutating, similar to our services. They should resources they are mutating, similar to our services. They should
inherit `Mutations::BaseMutation`. The fields defined on the mutation inherit `Mutations::BaseMutation`. The fields defined on the mutation
will be returned as the result of the mutation. are returned as the result of the mutation.
#### Update mutation granularity
GitLab's service-oriented architecture means that most mutations call a Create, Delete, or Update
service, for example `UpdateMergeRequestService`.
For Update mutations, a you might want to only update one aspect of an object, and thus only need a
_fine-grained_ mutation, for example `MergeRequest::SetWip`.
It's acceptable to have both fine-grained mutations and coarse-grained mutations, but be aware
that too many fine-grained mutations can lead to organizational challenges in maintainability, code
comprehensibility, and testing.
Each mutation requires a new class, which can lead to technical debt.
It also means the schema becomes very big, and we want users to easily navigate our schema.
As each new mutation also needs tests (including slower request integration tests), adding mutations
slows down the test suite.
To minimize changes:
- Use existing mutations, such as `MergeRequest::Update`, when available.
- Expose existing services as a coarse-grained mutation.
When a fine-grained mutation might be more appropriate:
- Modifying a property that requires specific permissions or other specialized logic.
- Exposing a state-machine-like transition (locking issues, merging MRs, closing epics, etc).
- Accepting nested properties (where we accept properties for a child object).
- The semantics of the mutation can be expressed clearly and concisely.
See [issue #233063](https://gitlab.com/gitlab-org/gitlab/-/issues/233063) for further context.
### Naming conventions ### Naming conventions
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment