51–60 of 71 posts
Curious to hear anyone's experience with RPC over Nameko in Python. We use it extensively on top of RabbitMQ and its been pretty robust.
1) Don't requeue on error. One bad message could bring down your entire service. Better to just push it to Sentry and make a fix for it.
2) Have a timeout in your message handler.
Anyway the problem with comparing rpc protocols is that you need to do a per case benchmark if you really care about performance. Pretty much every decent solution will be better than another equally good solution depending on the use case.
Years ago, one of my customers told me he used to work doing high frequency trading in a bank, and the bank had several tailor made solutions for data serialization and RPC made for very specific cases, and they were just better than any generic solution.
No mention of authentication or encryption? I can’t believe that everyone is either using HTTPS with either client certificates or plain HTTP authentication, or using IPsec (or some form of IP tunneling) to make encryption transparent to the application.
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/
Surprised article didn’t include this in its comparison. Seems an obvious contender.
Earlier quoted context omitted.
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.
Quick reminder that rebuttals are more valuable than downvotes.
Assuming that two endpoints are using the same or forward-compatible schemas, there's no "assumption" involved: if you sent a message of type T, it gets decoded as type T. There isn't protection against inauthentic messages, admittedly.
Would you like to cite an RPC scheme that meets your definition of type safety.
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…
Came here to say something similar. The interfaces and tooling around gRPC in the public sphere is pretty bad. If you maintain a code base with multiple languages and want to compile gRPC for it you can choose between: 1. Having a complex build system that is aware of gRPC 2. Massive migraines Unfortunately build systems integrations, IDE integrations, and generated code is unanimously awful for gRPC. Every company I…
Earlier quoted context omitted.
Be careful using the pickle format; it's not considered safe to unpickle untrusted data. https://docs.python.org/3/library/pickle.html
I did see the big warning labels everywhere. However, there is simply no replacement that is equally fast (protocol 5), easy to use (copyreg) and imports necessary modules when deserializing. So tradeoffs were made.
This is one of the fundamental security issues.