5 ms·

Ask HN: Using gRPC+protobuf is painful. Any nice-to-use alternatives?

• matt_the_bass 9y ago
  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.
• grizzles 9y ago
  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.
  • Veratyr 9y ago
    Have you seen https://github.com/grpc-ecosystem/grpc-gateway 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.
    • grizzles 9y ago
      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-client https://github.com/gabrielgrant/grpc-bus-websocket-proxy-cli...
      • weitzj 9y ago
        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 https://github.com/moul/protoc-gen-gotemplate We use this right now to generate an Elm JSON client for grpcgateway (without Swagger)
• Veratyr 9y ago
  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?
• shortoncash 9y ago
  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.
• wocram 9y ago
  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)
• weitzj 9y ago
  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
• jackyb 9y ago
  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.
• zackangelo 9y ago
  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 https://github.com/zackangelo/grpc-intro-scala