Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RPC Olympics – The Search for the Perfect RPC Protocol

perimeterx.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#11

Post by pathseeker »

mappu wrote: post #4

I performed the exact opposite migration at $DAYJOB recently - swapping an internal text-based protocol to HTTP (over a local IPC pipe). The main benefit was we could suddenly reuse all the codegenerated routers/docs/authentication from the HTTP ecosystem. It significantly simplified/standardised our IPC layer and reduced the "weirdness" in the codebase.

Yep. Unless you're doing thousands of requests per second+, the right RPC protocol is likely just HTTP due to the massive improvement in mature tooling, debugging, etc.

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#14

Post by alfalfasprout »

Having just looked into this recently, I can also safely say that moving to REST HTTP/2 on its own already provides a significant speed benefit. Closing the gap to GRPC (or even substantially beating it) is possible by switching to a fast serialization format (eg; flatbuffers, msgpack, capnproto).

While GRPC has its place it also comes with headaches like pretty lousy generated interfaces, horrible debuggability, and unpredictable scaling.

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#15

Post by parhamn »

Cool! I don't know if a comparison of these really makes sense. You'd be conflating transport, serialization, and stream format (unary/stream).

For fullstack dev, I've been immensely happy with grpc/protobuf over http because of the type safety I get communicating between Golang and Typescript. This eliminates a whole class of bugs but is only a serialization benefit.

Generally: use the thing with the best tooling!

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#16

Post by alfalfasprout »

pkage wrote: post #2

Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://zeromq.org/

ZeroMQ and its bindings are well-proven, extremely well written, and the ZeroMQ guide is a work of art. That said, the bindings are not created equal. We've seen some unreliability with the Java package even though the official C/C++ and Python bindings work perfectly (the Go package too).

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#18

Post by JoshTriplett »

nurettin wrote: post #10

My current rpc model for python is to pickle function name and args/kwargs and publish to redis for any subscribers that might be listening. If the channel is marked as persisting, I put the message to a hashset with current nanosecond as the timestamp and just send a ping instead. It is pretty fast with asyncio redis client clocking at an avg 15k rpc/s on a single core with uvloop on a lowly i7

Be careful using the pickle format; it's not considered safe to unpickle untrusted data. https://docs.python.org/3/library/pickle.html

Re: RPC Olympics – The Search for the Perfect RPC Protocol

#19

Post by silasb »

I recently spent some time between raw UDP and GRPC and learned a ton. This was for a hardware project so it's different from what web devs typically work on.

The most important thing that I found out while doing my research is it's not the fastest bytes that win. Well, that does matter, but it's not that important. It's reducing performance variance [1]. While my project wasn't optimizing for speed, it was optimizing for zero-copy de/serialization, but this often ends up as a solution for high-speed transfers. SBE, Flattbuffers, Cap'n Proto all had their places, but I ended up not using any of those and just hand-rolling something similar to what SBE would do. If this was a $DAYJOB project I'd probably end up doing something with SBE.

[1]: https://speice.io/2019/07/high-performance-systems.html

Post reply on HN