Do the Java gRPC tutorial - you may need to read some other stuff on grpc.io to understand protobuf syntax and the point of certain things in gRPC land.
Create a shake endpoint for Yoda
You'll need to create a yoda.proto in jukebox/protos
Add build rule 'build-yoda' to Makefile
Amend yoda to the list of directories protos is copied to (Makefile:25)
Add java grpc build command(s) to Yoda's Dockerfile
Consider using Server.java for your server implementation class' name
Write a little client Class whose main just sends a RPC call to the Shake endpoint and print it to sdtout
Expose the correct port (let's use 37000) on the Docker container
The way I'm envisioning the build process:
"User says 'make build' or 'make build-yoda' which copies the protos from /protos to yoda/protos"
Then they say docker build (or use a built image) and docker run. The image should have the protos compiled in the src code - which requires you to, in the Dockerfile, as part of container build, build the protos (look at genius Dockerfile line 15 for ex)
when we run our images, we map the src directory from the host FS to the container's (for better dev experience)
however, I want to compile protos inside the container (as part of the image build process)
this means that protos get created in ..yoda/src/protos at build time, but then at run time, we map the host FS' sec directory which doesn't have a compiled src/protos directory
my proposed solution:
short term: let's just not map our sec directory at runtime. This will make the development experience subpar
you can either completely do all development an building and running inside container
or you can just build the docker image before running it each time (and develop on your local machine normally)
long-term: I'm gonna try to figure out what the right solution to this is. I'm sure it's a problem faced by others. Maybe we build the protos at runtime? But that feels wrong to me. Hopefully we can exclude a single directory (protos) from being mapped over?