
Show HN: An Example Microservice Back End for Kubernetes, Bazel, Go, Java, GRPC - biggestlou
https://github.com/lucperkins/colossus
======
infinitone
> Getting all of these technologies to work together was a real challenge. I
> had to dig through countless GitHub issues and dozens of example projects to
> make all these things work together. I'm offering this repo as a starter
> pack for other people with a Bazel monorepo targeting Kubernetes.

So, if it was such a hassle just to get them all glued together- how would
they fair for a project that adopts it and matures?

~~~
biggestlou
It was a hassle mostly because a lot of the libraries are new and the
interfaces are still changing a lot. Bazel is a fantastic build tool that I'd
recommend for large projects. The Bazel + gRPC story, though, has a ways to
go.

But I don't see any reason why you shouldn't use Bazel + gRPC for a larger
project. You may have to tweak small things in the future but I suspect that
the UX will only improve. Plus, you can always write your own Skylark rules if
Bazel isn't cutting it for you in some way.

~~~
deklerk
Could you describe some of the bazel + grpc problems you had? I haven't used
grpc with bazel yet, but would love to hear problem areas.

~~~
kajecounterhack
It's been a while since I looked at this but ~6 months ago I was surprised to
find that there are no official bazel rules you can just import to make gRPC
"just work." As a result various third-party incarnations exist and they
differ slightly in their usage. When you try to compile a basic service it's
pretty frustrating.

I really wish gRPC team would come out with rules you can import and best
practice examples / tutorials :(

(I work at google but opinions are my own. I don't work on gRPC. I don't have
to write much skylark normally because Google infra teams write the common
rules you need. I found that writing my own skylark for project outside of
work isn't that fun.)

~~~
biggestlou
Things have improved but only marginally. Java and Go are the only languages
that have "native" gRPC support in Bazel. For others you need to rely on an
external repo whose connection to Google is unclear
([https://github.com/pubref/rules_protobuf](https://github.com/pubref/rules_protobuf)).
I find this disappointing, as a gRPC-connected microservice architecture that
Just Works and easily interoperates with Docker/Kubernetes/whatever seems like
it could be THE "killer app" for Bazel. I built this project to say "look,
it's easy!" But alas, it wasn't, and I've communicated that to some core Bazel
folk.

------
codesuki
We are using a similar setup. K8s, Bazel, Go, Java (Android), Swift (iOS),
Typescript. Everything with gRPC. I really like Bazel because it makes working
with Protobuf so much cleaner (at least in theory) and allows us to have one
build system for all those languages (at least in theory).

The easiest to set up was Go. Go support is already very good, including gRPC
and Protobuf. The only drawback was that it breaks editor integration of some
tools / linters because of the different directory layout for generated files.

Vanilla Java also has good support but when you go to Android land things
change. At first we had to use a custom fork of grpc-java to build for
Android, but with this change [https://github.com/grpc/grpc-
java/pull/4289](https://github.com/grpc/grpc-java/pull/4289) we were able to
go back to the main repo.

gRPC-web was a prohibitively large dependency for our front end. After all we
switched to a JSON API (using Envoy). I read that Google uses gRPC for
products like gMail and since Google is so obsessed with web performance I
wonder how they manage the dependency size (a few 100kb for us). There is a
lot of information scattered around like a json-proto protocol (not publicly
available?), which apparently should not be needed with proto3 and newer
browser because performance is supposed to be similar. grpc-web uses the
official protobuf/javascript package, using protobuf.js the dependency size as
well as the compiled protobuf might be smaller.

While building Swift and Objc for iOS was super easy with Bazel we couldn't
manage to build our protobuf/grpc. There were no working rules at the time and
we had no time to fix it completely which is why we are not building that part
with Bazel, yet.
[https://github.com/pubref/rules_protobuf/issues/188](https://github.com/pubref/rules_protobuf/issues/188)

I'd appreciate any insights you have on Objc support and grpc-web. It'd be
great to be able to use grpc across the whole stack.

------
rhacker
I'm using GRPC-ish stuff in my stack. I would say that one large hole with
grpc right now is figuring out the local development story. I am all on-board
with running databases in local Docker/local k8s, but still having trouble
wrapping my head around local grpc-web development given that grpc-web repo
seems completely stalled right now.

~~~
jzoch
I am using improbable-webs grpc-web[0] right now and it works very well once
some kinks were worked out. Only problem has been lack of client-side
streaming.

Additionally, I use grpcc[1] to test calls locally and that has worked well. I
originally tried using some GUI's that looked promising but couldnt get them
to work. This is good enough and less work than writing a quick client in
python.

[0]: [https://github.com/improbable-eng/grpc-
web](https://github.com/improbable-eng/grpc-web) [1]:
[https://github.com/njpatel/grpcc](https://github.com/njpatel/grpcc)

------
fons
Nice, here is a project with very similar goals and which runs in other
orchestrators other than Kubernetes: [https://microservices-
demo.github.io/](https://microservices-demo.github.io/)

~~~
infinitone
Used to be a fan of weave as a CNI. But i've never actually heard anyone or
team using them, it seems consensus is on calico or flannel?

~~~
bboreham
Weaveworks’ focus has been on visualisation and observability for the last
three years, and now deployment (GitOps).

BTW Weave Net has been “docker pull”ed 30 million times. _Somebody_ must be
using it...

(I work for Weaveworks)

------
sp527
Is it weird that I use most of this stack already but still thought the repo
was an attempt at satire? I feel like this experience has left me questioning
everything I think I know.

~~~
biggestlou
Just out of curiosity, what about it strikes you as potentially satirical?

~~~
slow_donkey
The cornucopia of buzzword tech

~~~
threeseed
RPC is 40 years old. Java is 20 years old. Go is 10 years old. Microservices I
saw at Apple over 20 years ago.

The real buzzword technologies are in the serverless space.

