Use gRPC now, not when HTTP+JSON becomes a problem?
After !37 (merged) I looked at gRPC a bit closer.
I like the fact that it generates glue code that makes RPC calls look like function calls. It might save us work writing wrapper code ourselves. So maybe we should skip writing that wrapper code and just use gRPC.
Update 2017-01-16: this is what I think it would look like.
Protocol definitions
The Gitaly repo contains the .proto definitions for RPC calls and all auto-generated client code.
Workhorse
- gitaly contains a go package
gitlab.com/gitlab-org/gitaly/client
that we can import in gitlab-workhorse, containing the auto-generated client code - pin gitlay client package dependency via Godep (manual gitaly version updates in workhorse)
Rails
- gitaly contains
ruby/gitaly.gemspec
that contains the auto-generated ruby client code (inruby/lib/gitaly
) - gitaly gem version is derived from the current tag in the gitaly repo
- gitaly gem version in in rails Gemfile.lock = gitaly server version bundled by omnibus (don't need GITALY_VERSION file)
- distribute gitaly gem via rubygems.org
Gitlab-shell
- in gitaly we create a
cmd/gitaly-shell-client
command to avoid issues with bundling a C extension in gitlab-shell - gitlab-shell gets a config option pointing to e.g.
/home/git/gitaly/gitaly-shell-client
- for the time being assume gitaly (server) software is installed on same machine as gitlab-shell, so that gitaly server update leads to an updated
gitaly-shell-client
executable