Comment by nu11ptr

6 months ago

Have you considered just using gRPC in this case? You gain 100% language separation (no FFI) and remote client/server at the cost of a little more call overhead.

Not OP but in same situation. Not every platform can run gRPC over localhost easily or without extra privileges.

I used to use protobuf but now I just use JSON, over stdin/stdout on desktop. It’s honestly quite good.

  • Which platforms? My product runs gRPC client/server on macOS, Linux and Windows. No issues with privileges. Or are you trying to run it on port 443? Yeah, don't do that, run it on 8443 or whatever instead.

    • Then you have to deal with port collisions when some other software wants to use that port. And keeping a port open without any authentication is terrible for security, even if it only binds on localhost, so you have to find some secure way to share a key between the client and server.

      Personally I wish we could just use UNIX sockets for "localhost-only TCP", but software support is just not there.

      2 replies →

Most of the gRPC implementations force buffering of the whole response for large unary responses. They are not really written by people who care about performance. It’s dumb because the protobuf binary marshaled format is perfectly designed for server-side incremental marshaling.

  • Performance is relative. gRPC is plenty fast enough for my use case, and for that matter, almost all client/server use cases that work across the Internet. If a Javascript web client against a REST backend is fast enough latency-wise, then a local gRPC connection on a single PC is gonna feel like greased lightning. Of course, there will be a few scenarios where tight coupling of client/server are required for good enough performance, but they are few and far between.