Apache Thrift VS baseplate.go

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.

We chose to use govips which is a cgo wrapper around the libvips image manipulation library. The majority of new development for services in our backend is written using baseplate.go. But Go is not an ideal choice for media processing as it cannot keep up with the performance of native code. The most widely used image-processing libraries like libmagick are primarily written in C or C++. Speed was a major factor in selecting libvips in order to keep latency low on CDN cache misses for images. In our tests, libvips was 3–4 times faster than libmagick on basic image processing operations. Content-aware smart cropping was implemented by porting smartcrop.js to Go. This is the only operation implemented in pure Go.

Even Reddit has python backends https://github.com/reddit/baseplate.py based on Pyramid. They also have a go one. https://github.com/reddit/baseplate.go

there's a multitude of services in reddit's architecture. as far as i can tell, they mostly using reddit's baseplate framework (which has implementations in both python and go).

FWIW, I believe Reddit has rewritten some Python into Go because of scaling issues. I don't know of any public write ups to confirm it, but at the least there's a public repo that contains their base template.

Gazette Inference Service is a baseplate.go (Reddit’s golang web services framework) thrift service whose single responsibility is serving ML inference requests to it’s clients. It is deployed with Reddit’s modern kubernetes infrastructure.

Baseplate is implemented in Python and Go, and although they share the same main functionality, smaller features differ between the two. One such feature that was previously on the Go implementation but not Python was deadline budget propagation, which passes on the remaining timeout available from the initial client request all the way through the server and any other requests that may follow. The lack of this feature in Baseplate.py meant that many resources were being wasted by servers doing unnecessary work, despite clients no longer awaiting their response due to timeout.