Grpc-java: google flatbuffer java support feature request

[ahundt]

While it has been discussed, I don't think there is an explicit feature request for grpc-java support of google flatbuffers, maintained by @gwvo, as a replacement for protobuf messages, initially integrated into the grpc c at https://github.com/grpc/grpc/issues/5438 and https://github.com/google/flatbuffers/commit/48f37f9e0a04f2b60046dda7fef20a8b0ebc1a70.

Use cases in grpc-java have also been mentioned in https://github.com/grpc/grpc-java/issues/2139 and https://github.com/grpc/grpc-java/issues/1403.

[carl-mastrangelo]

Not sure if we have manpower right now to implement flatbuffer code generation. We don't personally use it that much (and neither to most of our users), so it would be hard to justify spending time on it.

That said, gRPC Java is just as extensible in this regard as grpc/grpc, so you could make your own MethodDescriptor.Marshaller.

What's the use case?

[aardappel]

Not having a lot of users for it and not supporting it is a bit of a self-fulfilling prophecy :)

For reference, other people requesting Java support: https://github.com/grpc/grpc/issues/5438 https://github.com/google/flatbuffers/issues/4109

Also, Go support was recently added: https://github.com/google/flatbuffers/commit/a31ddd2bb38f719996137c9c35bc702f2abaefa5

[ahundt]

Any group using protobuf + grpc for soft real time or other low latency applications could benefit from this as flatbuffers are designed for lower unpacking overhead and flatbuffers provides a schema converter from protobuf to flatbuffers. A general example use case would be Android multiplayer games.

I'm using flatbuffers on a robot, specifically the kuka iiwa in the library grl which communicates from a C++ client to the Java robot API. Latency is key in this application, particularly on the C++ side which is one of the strongest aspects of flatbuffers. Right now I'm just serializing the whole message directly to a UDP packet, but other components of the system will be scaling up soon which must carry data that can't fit in a single UDP packet and for which their implementation will vary between C++ and Java components.

[carl-mastrangelo]

@aardappel I agree, definitely chicken and egg. However, like I said, we don't really have the headcount at the moment, and there are several other features that are blocking gRPC usage (like load balancing, monitoring, tracing, reflection, and caching). Is flatbuffers more important than those?

@ahundt : from what I have seen, people who are interested in very low latency use SBE. Regardless of which one is better, where is there more usage?

[ahundt]

The most commonly used communication mechanisms I'm aware of in robotics are:

1. ROS + rosmsg
2. Protobuf + one of grpc, ign-msgs, ZeroMQ, custom message protocols
3. DDS (used by some companies plus will be used by ROS2
4. Custom Stack (example: https://github.com/lcm-proj/lcm)

Flatbuffers is actually very small in this respect, but the performance advantage should be an improvement on protobufs. For true hard real time actually grpc likely isn't an option, but it works well for many higher level APIs.

By sbe do you mean https://github.com/real-logic/simple-binary-encoding?
Had not heard of it before, thanks!

[carl-mastrangelo]

@ahundt Protobuf should be seeing some serious perf improvement this quarter, which will probably make a lot more splash than FB. The cost of adding FB support is that it comes at the cost of other features. I mention SBE because it also competes with proto on speed.

As I said, our push back is based on scarcity of heads to work on this. If you are interested in contributing the code generator and marshallers, we would be interested in having it. We have already experimented with adding thrift support if you are looking for an example on how to add another codec. (though, it hasn't seen much uptake).

[ahundt]

Well if protobuf improves dramatically that would be great too!

Don't worry, I understand you have other requirements and time pressures. Perhaps I had just misunderstood your question regarding where there is more usage.

As for FB in grpc-java, of course it can remain outstanding until someone can implement it. :-)
Thanks for your time/feedback!

[ejona86]

It would be nice to have flatbuffer support, especially for Android games or servers powering soft real time applications (games, robots, etc). Making the marshaller should be pretty easy, the slower point would be for codegen support. It's not technically difficult, just takes some time.

[ghost]

At least for C++ and Go, we were able to adopt the existing codegen without too much work, so hopefully for Java it is the same.

[pam2014]

Any update on whether gRPC-FlatBuffer support is up and running for Java?

[aardappel]

@pam2014 : I'm afraid we still don't have anyone working on it. I'm not able to start on this myself any time soon, so I'm hoping someone else is able to take it on.

[mrZizik]

What is status of this? Maybe someone can show point where i can start implementation by myself?

[aardappel]

@mrZizik The Go support mentioned above might be a good starting point to see what would be needed for Java. That's the FlatBuffer side of things though, I'm not sure how grpc-java works internally, and wether it has any hardcoded dependencies on protobuf that may need to be factored out.

[ejona86]

grpc-java doesn't have any hard-coded protobuf dependencies. You basically make a MethodDescriptor.Marshaller and then make generated code classes. But it also doesn't have a convenient library to make your own code generators.

For client-side they extend AbstractStub and can use ClientCalls and server-side uses ServerCalls. You can take a look at protobuf-lite and thrift in the repo today for examples of the Marshaller. compiler/ in the grpc-java repo is the protobuf code generator.

[mrZizik]

We use clientcalls and servercalls instead of services in protobuf?

[ejona86]

@mrZizik, I don't understand your question.

[mrZizik]

@ejona86 You have

syntax = "proto3";

option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

package helloworld;

// The greeting service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}

}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

In grpc+protobuf you send Message via Service.

In grpc+flatbuffer we have tables instead of Messages, but what we use instead of Service?

[aardappel]

@mrZizik https://google.github.io/flatbuffers/flatbuffers_guide_writing_schema.html (search for rpc)

[yfinkelstein]

I have made changes to flatc compiler to generate gprc bindings for grpc/grpc-java framework. I followed the same path as taken for bindings generator for c++. I took https://github.com/grpc/grpc-java/tree/master/compiler/src/java_plugin/cpp and modified it to work inside flatc. It was pretty straightforward, although longer term question is how best to maintain it (see comment as the bottom of this). My fork containing the changes is here:

https://github.com/yfinkelstein/flatbuffers.

I also forked and enhanced the work of @davidmoten here: https://github.com/yfinkelstein/flatbuffers-java:

My changes:

1. I created the binary of my version of flatc for mac (and soon for linux) here: https://github.com/yfinkelstein/flatbuffers-java/tree/master/flatbuffers-compiler/bin/osx
2. I created a new utility jar containing utility classes referenced by generated grpc bindings for flatbuffers: https://github.com/yfinkelstein/flatbuffers-java/tree/master/flatbuffers-java-grpc
3. I created a new example project demonstrating usage of grpc client/server interaction using flatbuffers formatted messages: https://github.com/yfinkelstein/flatbuffers-java/tree/master/example-grpc. I decided to create a separate project since the unit test there needs flatbuffers-java-grpc and netty while the original example project is dedicated to demoing pure java/flatbuffers code.

I would like to check in the code back to google/flatbuffers. I will submit a pull request, but I'm not sure how google intends to maintain it moving forward as grpc/grpc-java will be evolving independently and someone will always need to sync the code generation code https://github.com/grpc/grpc-java/tree/master/compiler/src/java_plugin/cpp/java_generator.cpp back into https://github.com/google/flatbuffers/tree/master/grpc/src/compiler/java_generator.cc (for now it's here https://github.com/yfinkelstein/flatbuffers/blob/master/grpc/src/compiler/java_generator.cc until the pull request is merged) which has diverged quite a bit.

This same problem exists for C++ grpc bindings generator as well btw. The code was taken from https://github.com/grpc/grpc/blob/master/src/compiler/cpp_generator.cc and adopted to replace protobuf artifacts with flatbuffers one. Since then grpc has evolved and the bindings became incompatible. I have also refreshed this generator to work with latest grpc 1.7.x and 1.8.x: https://github.com/yfinkelstein/flatbuffers/blob/master/grpc/src/compiler/cpp_generator.cc

[ejona86]

The compat problem should be less severe in Java than C++. In Java we can't assume protoc-gen-grpc-java and grpc-java runtime versions match, so the generated code can only use stable APIs. In C++ they do assume the versions match, because there aren't really package managers in C++ shipping binaries. And even if they were, protobuf would probably be statically linked or similar.

Now, the stub can be "stale" as in "not modern," or trigger @Deprecated compiler warnings. But it should rarely break outright.

[aardappel]

Thanks, this work is really appreciated :)
As for keeping it up to date, yes the situation is unfortunate, but depending directly on gRPC (and the various language projects) would not be great for most of our users. So we put up with manually updating the dependencies.

[xiaohaoliang]

good!
https://github.com/google/flatbuffers/pull/4558

[bubenheimer]

I wonder how ready this is for production use. @ejona86 captured my client and server use cases well, my goal is to store & access protobuf data in a marshalled format on both client & server, as this appears to be the most sensible way to deal with it. I have partially implemented this on the server, and am about to make similar changes on the client. Currently I simply use protobuf byte arrays, but especially for the Android client it would be great to do the pervasive unmarshalling in a more performant manner; for the server reduced load is always better, too. SBE sounds interesting but I'm pretty sure I will not be able to allocate bandwidth for incorporating SBE in the foreseeable future, or even be willing to tolerate the additional complexity that SBE would add to the project in general.