The main contenders I've seen are gRPC and Cap'n'Proto.

I vastly prefer gRPC (Cap'n'Proto's documentation leaves a lot to be desired so it's difficult to use, gRPC comes with threading built in, Capnp does not) and aside from some performance issues, have had zero problems with it.

What kinds of objects are you having issues with? I suspect the problem isn't gRPC/protobuf so much as the code you're using to interact with it. How exactly are you using it?

You should try to separate the protobuf/grpc code from your Java code once and use it to integrate with your Java classes, which make most sense to you.

There was a blog post around 3 months ago which went in this direction: use it to abstract transport/serialization, but don't try to force your whole business domain into this

You should treat them just as containers for data to be serialized. If you require fields to be set on an object, you’re going to want to create a set of classes that enforce those constraints.

If you’re thinking about switching to Scala, the gRPC support in the scalapb library is mature and easy to use.

You can check out the slides from my gRPC+Scala talk here: https://github.com/zackangelo/grpc-intro-scala

What about ROS? They have pubsub, services (like HTTP), actionlib (basically like a progress event) and message code generation. They also have entire suite for debugging and logging the communications (e.g. rostopic, rosservice, rosbag, etc..). They even have rosbridge_websocket if you need web apps to interact with native apps and servers. They are also building ROS 2 which might be even nicer.

I like grpc but I wish it was easier to use from the browser. My favorite solution on github only has 5 stars.

> failing to set attributes as protocols have evolved over time has been a genuine problem.

Can you explain what you mean? The evolution of datagrams seems like it's one of grpc's core strengths.

Have you seen https://github.com/grpc-ecosystem/grpc-gateway? It generates a reverse proxy that converts proto <-> JSON and will even output a Swagger definition you can use with a JS client library.

I didn't know about the swagger bit. That sounds cool; I'll check it out. This is the one I meant: https://github.com/gabrielgrant/grpc-bus-websocket-proxy-cli...

There is grpc web in the works, but that will take some time. We use the swagger route and the grpcgateway. Check out the CoreOS blog post.

Also a really great tool is https://github.com/moul/protoc-gen-gotemplate We use this right now to generate an Elm JSON client for grpcgateway (without Swagger)

I like ZeroC's ICE and I use it as a form of component interconnect where appropriate. The pain level is minimal (although I disliked some elements of how they distributed their packages over the years.) Source builds have been problem free.

We’ve been using protobuf plus zmq for years. It works well for us, is pretty simple and works well.

We use it in python, c++, and Matlab. We can easily separate processes across multiple computers with little effort.

This is an issue with protobuf, not grpc, right?

If you can figure out exactly which part your complaining about you should be able to automate it (eg. generating the boilerplate using reflection in java)