Example project: Go/Gazelle, Java, gRPC, Docker, Kubernetes

[Luc Perkins]

Hey everyone,

I just wanted to point you all to an example project I built that, I think, does a decent job of showing how Bazel can be used in a multi-lingual, microservice-driven setting. I'm calling it Colossus for no particular reason:

https://github.com/lucperkins/colossus

Everything is built by Bazel. It includes a Go HTTP service as a front end and two backend services (an auth service in Go and a data service in Java). All of the Go stuff uses vendoring via the dep tool and Gazelle. The auth service interacts with Redis. The data service will eventually interact with some database, maybe Cassandra or something. The next step in the project from a Bazel perspective will be to test out the Kubernetes rules, which seem very promising. I'd also like to include services in more languages once Bazel + gRPC support exists for them (Go and Java seem to be the only languages that are well supported at this point).

Feedback more than welcome! Please feel free to submit issues or PRs. I'd like for this project to really represent the "state of the art" in Bazel, i.e. to represent best practices and show off what Bazel is capable of providing in a project like this.

Luc

[of...@google.com]

Hey!
Great work! Thanks for doing, open sourcing and posting it here :-)
I"m working on a similar project:
https://github.com/google/startup-os

I've mostly tackled Java 'till now, and then someone came along and started contributing C++.
Would you like to add your Go contributions to StartupOS? With attribution of course.
I'm thinking of setting up Gitter and having per-language channels, so we can all support each other :)

Thanks again! Great stuff.
Ofer

[Jay Conrod]

This is really cool! Thanks for posting this.

Any thoughts on how rules_go and Gazelle can be improved to make this easier? I realize our documentation and examples can be improved a lot. What other pain points did you run into?

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/d4ef4d68-22b0-4340-8a7e-02de976bf12b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luc Perkins]

One thing that stung me was that I ended up needing to use a “# keep” statement on a go_library statement to force it to use the version of gRPC for Go that’s imported in the WORKSPACE file (rather than the vendored version). Otherwise there’s a dependency conflict.

It would be great if there were a go_grpc_library rule that Just Works the way that java_grpc_library does.

Or if there’s a way around this that I’m missing, let me know and I’d be happy to fix.

[Jay Conrod]

With gRPC, yeah, it's definitely best to use the external version rather than a vendored version. The plugins defined in rules_go will depend on the external version directly.

in general, when you have both external and vendored versions of a library, Gazelle will prefer the vendored versions. You can tell Gazelle to ignore your vendor directory by adding "# gazelle:exclude vendor" in your root build file. So that may be useful since you imported all the dependencies into WORKSPACE.

We should probably add a special case to Gazelle's dependency resolution to use the external version of gRPC. I've filed bazelbuild/bazel-gazelle#217 to track that.

[Luc Perkins]

Excellent! The workaround you suggested is preferred, I think, to the “keep” workaround, in my opinion. I’ll make that change in my project.

I do concur that the gRPC case merits an exception to the Gazelle default. It would also be nice to be able to override that behavior in Gazelle’s configuration. I made a note in the GitHub issue.