Setup

Save to the WORKSPACE file.

Defining the gRPC in Protocol Buffers

Save this to proto/transceiver.proto.

Let’s take a moment just to analyze these definitions. We locally define two messages EchoRequest and EchoResponse to contain the request and response to the RPC, respectively.

Notably, within both EchoRequest and EchoResponse, we include the earlier created TransmissionObject message. Strictly speaking, there is nothing required in having the same message being included in both the request and the response; we do this here only to mirror the functionality that we have created in prior chapters. Additionally, nothing requires having the messages for the request and response defined within the same file as the interface; we do so here only for the sake of simplicity.

We then define a service Transceiver, within which we have a single RPC, Echo. In the definition of Echo, we defined the required request and response.

Finally note that all we are doing here is defining the interface for our RPC. Beyond that, nothing (here) defines its implementation.

Save the file to proto/BUILD.

As with the proto code, let’s examine what we’ve added here. The first new build target should look familiar; it simply defines the proto_library target for the transceiver.proto file. In a similar fashion, transceiver_java_proto should also look very familiar, as it defines the build target for the Java version of transceiver.proto.

The transceiver_go_proto_grpc looks very similar to what we have seen previously; the primary exception is addition of the compiler directive within go_proto_library target. This defines the rule that should be used when compiling the target in order to support gRPC. We use the standard rule found within the @io_bazel_rules_go dependency.

Since we are using Go only on the server side, we set the visibility to only the server subpackages.

The java_grpc_library does a similar job, except for defining the necessary target for Java. In a complementary fashion, we set the visibility to only the client subpackages.

Upgrading the Client to Use gRPC

Having defined the gRPC interface, we will now upgrade the client to use it. For the most part, the code will look very similar to what we had done previously. We will highlight a few of the changes that are needed for the basic version.

We had previously created a Java client that explicitly transmitted a serialized object. We will make some modifications to the support using gRPC.

Save the file to client/echo_client/command_line/EchoClient.java.

Taking another moment to examine the changes, we first create a ManagedChannel to open a channel on a specific port. This is then used to create a stub (TransceiverBlockingStub) for actually making the RPC. For the sake of simplicity, we use the most basic of stubs, which makes blocking calls for all of the service’s RPCs (other, more flexible versions of the stub are possible, but are outside of the scope of this book).

The stub provides local methods which forward the calls through the channel. Once created, the stub makes it as easy to call an RPC as it would be a local method. The request is formulated and then used to call into the method, with the expected response.

Save the file to client/echo_client/command_line/BUILD.

For what might be obvious at this point in time, we’ve added the new dependencies from the proto subpackage. Additionally, we’ve added both a typical static dependency (@io_grpc_grpc_java//api) as well as a new runtime dependency (@io_grpc_grpc_java//netty).

In this latter case, we specify that this is a runtime dependency since it is not explicitly requested in the code. If you attempted to remove runtime_deps, you would find that building the program would work perfectly fine. However, attempting to run the program would result in an error message requesting the runtime dependency.

Notably, we won’t be able to actually run the client yet; although we’ve successfully created a client that uses gRPC, we still need a service that implements the RPC.

Upgrading the Server to Use gRPC

To upgrade our server to use gRPC, we will need to register and fill in the functionality for the RPCs. gRPC generates most of the scaffolding for us; we just need to register our server and provide the appropriate methods to fulfill the contract.

As with the prior section, we can make some modifications on our existing code. Notably, in this case, we will be making more extensive modifications in order to support gRPC.

Save the changes to server/echo_server/echo_server.go.

Once again, let’s take a step back to examine the major changes. In this case, you’ve created a Go struct EchoServer which has a specially named method Echo.

Save your changes to server/echo_server/BUILD.

As before, the new org_golang_* dependencies are not invented from thin air; they’ve come from the Go dependency that we had defined within the WORKSPACE file.

Running the Client and the Server

Having completed both the client and the server, we are ready to actually use our new functionality.

As with your prior implementation, you see the message that was sent by the client. However, there is one important difference to the functionality here: the server has not exited. That is, the server is still running and waiting for new connections to come in.

This persistent functionality is available “out of the box” with gRPC. In switching over to it, we’ve actually gained more functionality for roughly the same number of lines of code.

Adding Another RPC

One complaint which could arise is that you have written roughly the same amount of code to perform the same actions as before. To further illustrate the power of what we have created, we will quickly add one more RPC to the entire system.

Save the file to proto/transceiver.proto.

Note that all that was necessary was simply adding the new RPC declaration to the service, along with some explicit messages for the request and response.

Save the changes to server/echo_server/echo_server.go.

Once again, note that all that was necessary was adding in the new method to the struct.

Save your changes to client/echo_client/command_line/EchoClient.java.

Once again, all that was needed was simple, to create the appropriate constructs and call the newly defined RPC. Let’s run a test to verify that all is well.

Congratulations! You’ve just added a new RPC into your system. Notably, this required only a little bit more code in each location (definition, server, and client). Moving forward, you could easily define vastly more functionality in a very ordered and well-managed fashion.

Final Word

Over the course of the last chapter, the focus was less on an any structural knowledge on using Bazel than using it in a manner closer to actual development. You saw how Bazel’s multi-language support worked hand in hand with gRPC to easily create new client–server functionality.

Up until this point in time in the book, the focus has been mainly on looking at functionality which effectively lives on a backend. That is, both the clients and servers created thus far could easily be proxies for backend services talking to one another.

Although much of the communication theme will continue moving forward, we will start to look at using Bazel to create purely client-side functionality in the form of mobile applications. Once again, we will lean heavily on Bazel’s ability to work seamlessly across languages to create these applications.