Apache Thrift VS gRPC

There are various notable implementations of RPC like Apache Thrift and gRPC.

> That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server.

No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

> Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/

Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea

Thus, we released Baseplate.py v2.1 with deadline propagation. Each request between Baseplate services has an associated THeader, which includes relevant information for Baseplate to fulfill its functionality, such as tracing request timings. We added a “Deadline-Budget” field to this header that propagates the remaining timeout so that information is available to the following request, and this timeout continues to get updated with every new request made. With this update, we save production costs by allowing resources to work on requests awaiting a response, and gain overall improved latency.

Here’s an example of the Thrift changelog. Knock yourself out. Or you can get your sense of productivity by actually doing something of value.

The biggest addition is native async reading via futures::AsyncRead and futures::AsyncSeek, which required a lot of (to be merged) changes upstream (changes to thrift rust compiler and parquet-format-rs). I placed those changes on a temporary crate until things are released there.

We were sharing instances of a Thrift TDeserializer across threads. We knew TProtocol was not thread-safe, but the TDeserializer constructor accepts a TProtocolFactory, so we naively assumed the deserialize method would use that to create a new instance of TProtocol for each invocation, but unfortunately, the TDeserializer constructor immediately creates TProtocol and stores it in a member variable, so TDeserializer is not actually thread-safe.

> I have personally found several fuckups in gRPC and protobuf code resulting in application crashes or risks of remote code execution.

Would be great if you report such remote code executions to the authors/Google. I am sure they handle CVEs etc. There have been security audits like https://github.com/grpc/grpc/blob/f5c26aec2904fddffb70471cbc...

> there aren't sanitizer builds nor fuzzing regime nor static analysis running against new commits last time I checked.

Are you making shit up as you go? I randomly picked a recently merged commit and this is the list of test suites ran on the pull request. As far as I recall, this has been the practice for 8 years+ (note the MSAN, ASAN, TSAN etc.)

Sonja Keerl, CTO of MACH Alliance, states, "Composable architectures enable enterprises to innovate faster by assembling best-in-class solutions." Developers must embrace technologies like GraphQL, gRPC, and OpenAPI to remain competitive.

Efficiency and Code Generation: Unlike traditional approaches like gRPC-Gateway, Vanguard operates efficiently within Go servers, compatible with various servers such as Connect and gRPC. It doesn't rely on extensive code generation, eliminating the need for additional code generation steps. This flexibility ensures that your code can adapt dynamically, loading service definitions from configuration, schema registries, or via gRPC Server Reflection, making it a perfect fit for proxies without the hassle of recompilation and redeployment each time an RPC service schema changes.

gRPC is a framework for building fast, scalable APIs, especially in distributed systems like microservices.

The Docker image, named getjv/grpc-php-base, provides the protoc compiler, the protoc-gen-grpc plugin, and the grpc.so extension.

Recently, I started working on extending the support for gRPC in GoFr, a microservices oriented, Golang framework also listed in CNCF Landscape. As I was diving into this, I thought it would be a great opportunity to share my findings through a detailed article.

I recently faced this issue while wanting to use the pyi file generation feature in the rules_proto_grpc_python rule set.

Apache Arrow Flight RPC : Arrow Flight is an RPC framework for high-performance data services based on Arrow data, and is built on top of gRPC and the IPC format.

gRPC Official Site: https://grpc.io/