Apache Thrift
Cap'n Proto
Apache Thrift | Cap'n Proto | |
---|---|---|
10 | 74 | |
10,735 | 12,296 | |
0.4% | 0.9% | |
9.3 | 9.1 | |
8 days ago | 5 days ago | |
C++ | C++ | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Apache Thrift
-
Symfony in microservice architecture - Episode I : Symfony and Golang communication through gRPC
There are various notable implementations of RPC like Apache Thrift and gRPC.
- What is gRPC popularity? I believe not very popular. And subreddit is small. Why is that?
-
Fresh – The next-gen web framework
> 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
- Ask HN: Who Wants to Collaborate?
-
Deadline Budget Propagation for Baseplate.py
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.
-
If someone ever asks you why you use Apollo, show them this screenshot.
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.
-
parquet2 0.3.0, with native support to read async
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.
- proposal: expression to create pointer to simple types #45624
-
Can you share your experience with race conditions in production?
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.
Cap'n Proto
-
Rust in the Linux kernel: part 2
My interest in Rust comes from getting frustrated with C's type system. Rust has such a nice type system and I really enjoy the ownership semantics around concurrency. I think that C++ written "correctly" looks a lot like Rust and libkj [1] encourages this, but it is not enforced by the language.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
-
Writing your own C++ standard library part 2
Have you seen libkj [1]? I've used it and really enjoy working with it. It has a rust-like owned pointer and the whole library uses these smart pointers.
It has proper container classes based on B-trees and its also got an async runtime.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/index.m...
- The first year of free-threaded Python – Labs
- Ask HN: Which Opens Source Software have the sexiest code?
-
Begrudgingly Choosing CBOR over MessagePack
Just curious if you considered Cap'n Proto as another option, or if it wasn't in the running?
[1] https://capnproto.org/
- Cap'n Proto: High-Performance Serialization and RPC for Modern C++
- The Simdjson Library
-
Demystifying the Protobuf Wire Format
To be fair, if that's what you need ProtoBuf isn't the only option. Cap'n Proto[1], JSON Schema[2], or any other well supported message-definition language could probably achieve that as well, each with their own positives and negatives.
[1]: https://capnproto.org/
[2]: https://json-schema.org/
-
Mysterious Moving Pointers
Yeah I pretty much only use my own alternate container implementations (from KJ[0]), which avoid these footguns, but the result is everyone complains our project is written in Kenton-Language rather than C++ and there's no Stack Overflow for it and we can't hire engineers who know how to write it... oops.
[0] https://github.com/capnproto/capnproto/blob/v2/kjdoc/tour.md
-
Show HN: Comprehensive inter-process communication (IPC) toolkit in modern C++
- may massively reduce the latency involved.
Those sharing Cap'n Proto-encoded data may have particular interest. Cap'n Proto (https://capnproto.org) is fantastic at its core task - in-place serialization with zero-copy - and we wanted to make the IPC (inter-process communication) involving capnp-serialized messages be zero-copy, end-to-end.
That said, we paid equal attention to other varieties of payload; it's not limited to capnp-encoded messages. For example there is painless (<-- I hope!) zero-copy transmission of arbitrary combinations of STL-compliant native C++ data structures.
To help determine whether Flow-IPC is relevant to you we wrote an intro blog post. It works through an example, summarizes the available features, and has some performance results. https://www.linode.com/blog/open-source/flow-ipc-introductio...
Of course there's nothing wrong with going straight to the GitHub link and getting into the README and docs.
Currently Flow-IPC is for Linux. (macOS/ARM64 and Windows support could follow soon, depending on demand/contributions.)
What are some alternatives?
gRPC - C++ based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)
ZeroMQ - ZeroMQ core engine in C++, implements ZMTP/3.1
Apache Avro - Apache Avro is a data serialization system.
FlatBuffers - FlatBuffers: Memory Efficient Serialization Library