diff options
| author | Patrick Steinhardt <psteinhardt@gitlab.com> | 2022-09-21 10:53:48 +0300 |
|---|---|---|
| committer | Patrick Steinhardt <psteinhardt@gitlab.com> | 2022-09-21 10:53:48 +0300 |
| commit | 1eda233db080a25773e13276ddf7cdeaf9c5011a (patch) | |
| tree | da1c2cad7aab2c311a290db5347dc78367f1ab3d | |
| parent | b4c1f29c487a41b2e69a31a99f6b0ac462c81ce4 (diff) | |
doc: Clarify GitLab/Gitaly boundary for RPCspks-docs-document-rpc-business-boundary
In the past it wasn't always clear where exactly we put the boundary for
RPCs that should be implemented in Gitaly versus those that should be in
Rails. This was recently clarified though: Gitaly should always avoid to
implement business-specific logic and policy. Instead, its provided RPCs
should focus on the problem-domains specific to Gitaly and Praefect.
Clarify this in our documentation to make it more readily discoverable
by engineers.
| -rw-r--r-- | doc/protobuf.md | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/doc/protobuf.md b/doc/protobuf.md index 4ed62296f..b5ce7b913 100644 --- a/doc/protobuf.md +++ b/doc/protobuf.md @@ -129,6 +129,16 @@ Common concepts that can be considered: with ambiguity and makes it possible to use RPCs for references which are not branches. +RPCs should not implement business-specific logic and policy, but should only +provide the means to handle data in the problem-domain of Gitaly and/or +Praefect. The goal of this is to ensure that the Gitaly project creates an +interface to manage Git data, but does not make business decisions around how to +manage the data. + +For example, Gitaly can provide a robust and efficient set of APIs to move Git +repositories between storage solutions, but it would be up to the calling +application to decide when such moves should occur. + ### RPC naming conventions Gitaly has RPCs that are resource based, for example when querying for a commit. |