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

21–30 of 71 posts

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

#21

Post by ngneer »

JoshTriplett wrote: post #18
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

You beat me to it. Sounds like you would be opening yourself up to a variant of CSRF. One user could upload untrusted data that would be fed into an unsuspecting user. You should never feed or consume an untrusted pickle.

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

#23

Post by treve »

alfalfasprout wrote: post #14

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…

It's kinda weird to compare REST to RPC protocols though. It's a completely different paradigm. Maybe you're just building a HTTP API without the REST part? (JSON-RPC is a thing)

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

#25

Post by cogman10 »

pathseeker wrote: post #11
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.

Today's toasters can handle 1k http requests per second. :)

The overhead of Http (especially 2/3) matters so little on modern hardware.

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

#26

Post by CameronNemo »

parhamn wrote: post #15

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!

I'd love to learn more about your stack, use cases, and development workflow. My employer is starting a golang, grpc/protobuf, and sveltejs web application from scratch and they are new technologies for almost everyone on my team!

I want to write my integration test suite for the back-end service in typescript to hopefully be able to reuse some of the test suite code for the front-end. But I'm struggling to set up a functional CI pipeline.

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

#27

Post by parhamn »

CameronNemo wrote: post #26
parhamn wrote: post #15

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!

I'd love to learn more about your stack, use cases, and development workflow. My employer is starting a golang, grpc/protobuf, and sveltejs web application from scratch and they are new technologies for almost everyone on my team! I want to write my integration test suite for the back-end service in typescript to hopefully be able to reuse some of the test suite code for the front-end. But I'm struggling to set up a…

Sure! We are actually currently building a platform on this stack (for eventual open sourcing) called Core [1]. Protobuf generally definitely needs some tooling and environment management work to make things smooth. But it is achievable and when you get there things work better a lot more often.

Drop me a line at parham@cloudsynth.com and happy to give guidance where I can.

[1] https://www.cloudsynth.com/products/core

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

#28

Post by thedance »

parhamn wrote: post #15

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!

There is no type safety in grpc or any other protobuf RPC scheme, full stop. The recipient of a message makes an assumption about the meaning of the message and decodes it accordingly. Any encoded protobuf might successfully decode as any other protobuf.

To repeat, grpc has no "type safety" whatsoever.

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

#29

Post by pdpi »

treve wrote: post #23
alfalfasprout wrote: post #14

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…

It's kinda weird to compare REST to RPC protocols though. It's a completely different paradigm. Maybe you're just building a HTTP API without the REST part? (JSON-RPC is a thing)

HTTP is a reasonable enough transport layer for RPC frameworks (e.g. gRPC is built on top of HTTP/2)

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

#30

Post by parhamn »

thedance wrote: post #28
parhamn wrote: post #15

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!

There is no type safety in grpc or any other protobuf RPC scheme, full stop. The recipient of a message makes an assumption about the meaning of the message and decodes it accordingly. Any encoded protobuf might successfully decode as any other protobuf. To repeat, grpc has no "type safety" whatsoever.

Give me whatever terminology you prefer for: "I can ensure I maintain backwards compatibility (with a spec checker). Also with most of the generated client code you can ensure to a high degree of safety that the data I'm accessing exists and is of the correct type".

Happy to consider using that term instead. For most folks, the one I chose is good enough.

Post reply on HN