Grpc-gateway: Bazel Rule?

[amit-traiana]

Hello,

I'm using Bazel to build a project consists of gRPC protobuf files, and would also like to generate a grpc-gateway/swagger along with that.

There's no build-in Bazel rule for the gateway, and the only alternative I could find was here. The problem with this rule is that it generated the main.go file for you, and in my-case, I already have a gateway main.go file I want to just compile and create binary from.

I noticed you guys using Bazel to build your code, so I was trying to compile the Gateway like a normal Go file with go_binary, but failed to consume grpc-gateway as remote dependency (maybe I missed something). Is that even possible? and if not - is there any alternative? or the only way I can compile a gateway/swagger is from command-line?

Thanks!

[amit-traiana]

I was able to compile the Gateway go file using Bazel, but it's a bit hacky. I'm sharing couple of core points, and perhaps someone knows of a better solution.

First, use http_archive to download the repository locally (in the example below I'm referencing the local repository as @com_github_grpc_ecosystem_grpc_gateway). Then load to go dependencies:

load("@com_github_grpc_ecosystem_grpc_gateway//:repositories.bzl", "go_repositories")
go_repositories()

Both are going into your WORKSPACE. When building the specific rules, the root go_binary or go_library of should depend on runtime like so:

deps = [
      **"@com_github_grpc_ecosystem_grpc_gateway//runtime:go_default_library",**
        "@com_github_golang_glog//:go_default_library",
        "@org_golang_google_grpc//:go_default_library",
],

The actual go_proto_library rule that is being reference by go_library, should have the following:

compilers = [
        "@io_bazel_rules_go//proto:go_grpc",
        "@com_github_grpc_ecosystem_grpc_gateway//protoc-gen-grpc-gateway:go_gen_grpc_gateway",
],

[achew22]

I'm not sure I understand the problem here.

You successfully added the grpc-gateway compiler to your go_proto_library so you should be able to use the grpc-gateway generated stuff from that. That is how rules_go is designed to work. Can you point me to the hack that you think there is?

WRT adding a dependency on the runtime, why would you expect that you could use code from the runtime without adding a dep to it? That's sort of bazel's thing, isn't it?

What's wrong with using our protoc_gen_swagger rule to generate the swagger json?

[amit-traiana]

Hello achew22 :-)

I miss-used the word 'Hack'. What I mean is that the above wasn't very 'straight-forward'. Take this other gateway rule I mentioned. It have a "public" rule called gateway_grpc_library, and all you have to do is to specify the deps. It will encapsulate the need to use the grpc-gateway compiler and stating the run-time dependencies.

What I currently do is almost accessing a "private" API in a sense, because I navigate inside the project and stating for example I'm using runtime:go_default_library. If by any change tomorrow you guys will restructure the project, the code above will break.

Now it's fine of-course if you guys prefer not to create a dedicated public rule for Bazel users. I'm just making sure if what I currently do is the recommend way.

Thanks!

[achew22]

I miss-used the word 'Hack'. What I mean is that the above wasn't very 'straight-forward'. Take this other gateway rule I mentioned. It have a "public" rule called gateway_grpc_library, and all you have to do is to specify the deps. It will encapsulate the need to use the grpc-gateway compiler and stating the run-time dependencies.

rules_proto is not in the bazelbuild organization, while rules_go is. rules_go has documentation on how they want you to add a compiler to a go_proto_library, and they are the canonical way of doing Go in Bazel.

We have runtime and utilities in our deps section which should automatically be added to any go_proto_library rule you create. If that's not the case, let's open another bug and figure that out.

What I currently do is almost accessing a "private" API in a sense, because I navigate inside the project and stating for example I'm using runtime:go_default_library. If by any change tomorrow you guys will restructure the project, the code above will break.

The runtime target, by virtue of having both public visibility for Bazel and by not being in a directory called internal for Golang are a part of our public api. As such if we were to modify them in an incompatible way it would be a breaking change and we would announce it as such.

To me, these seem like public rules. Maybe you could speak about what is missing from them that would make them more "public"? I'm asking for specific and actionable feedback here. I'd like to make things better, but I don't know how. Maybe a PR or a sample repo describing your issue would be useful to understand as well.

[amit-traiana]

I'm asking for specific and actionable feedback here. I'd like to make things better, but I don't know how. Maybe a PR or a sample repo describing your issue would be useful to understand as well.

Completely understand. This issue was originally opened as a question. To figure out if I'm consuming and using your Bazel build files correctly from a remote Bazel build system. You seems to approve of that way, and that's enough for me as for now. In case I'll have a more concentrate example on what I think can be improved, I'll open a detailed PR and sample repo as you rightfully requested.

Let's close this issue, but just in-case I'm attaching a minimal example on how I did things. People might find it useful, as the examples on the grp-gateway repo assumes your working locally and not remotely.

Thank you achew22 ! :-)

[amit-traiana]

Oh, @achew22 - forgot to mention something. grpc-gateway using bazel_gazelle as dependency. Because you don't have deps.bzl file, I set the import to bazel_gazelle in my project, even though I don't directly use it. Care to add or accept pull request for deps.bzl file?