Cap'n Proto
Apache Thrift
Our great sponsors
Cap'n Proto | Apache Thrift | |
---|---|---|
64 | 10 | |
11,069 | 10,097 | |
1.7% | 0.4% | |
9.3 | 8.9 | |
9 days ago | 7 days ago | |
C++ | C++ | |
GNU General Public License v3.0 or later | Apache License 2.0 |
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.
Cap'n Proto
-
I don’t understand zero copy
The second one is to encode data in such a way that you can read it and operate on it directly from the buffer. You write data in a layout that is the same, or easily transformed as types in memory. To do that you usually need to encode with a known schema, only Sized types to efficiently compute fields locations as offsets in the buffer, and you usually represent pointers as offset into the encode. You can look at capnproto protocol for instance https://capnproto.org/
-
OpenTF Renames Itself to OpenTofu
Worked well for Cap'n Proto (the cerealization protocol)! https://capnproto.org/
-
A Critique of the Cap'n Proto Schema Language
With all due respect, you read completely wrong.
* The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to talk between sandbox and supervisor -- an explicitly adversarial security scenario.
* The documentation explicitly calls out how implementations should manage resource exhaustion problems like deep recursion depth (stack overflow risk).
* The implementation has been fuzz-tested multiple ways, including as part of Google's oss-fuzz.
* When there are security bugs, I issue advisories like this:
https://github.com/capnproto/capnproto/tree/v2/security-advi...
* The primary aim of the entire project is to be a Capability-Based Security RPC protocol.
-
Sandstorm: Open-source platform for self-hosting web app
I like how they use capability-based security [0] and use Cap'n Proto protocol. This is another technology that is slow to get broad adoption, but has many things going for when compared to e.g. Protocol Buffers (Cap'n Proto is created by the primary author of Protobuf v2, Kenton Varda).
-
Flatty - flat message buffers with direct mapping to Rust types without packing/unpacking
Related but not Rust-specific: FlatBuffers, Cap'n Proto.
-
Distributing data with a binary
Cap'n proto would be ideal for this. It can read out the data from a const byte array (using include_bytes! macro) directly without a separate deserialise step. protobuf and bincode would require deserialising the data into a heap allocated structure on startup or first use. Because your binary will be memory-mapped by the OS, the data can also be lazily paged in as it is read, requiring less I/O if you don't read the whole file.
-
Any sort of plugin engine with dynamic load ability and any limitations?
This is only possible when you don't need serialization, though. However, just last week I started looking into Cap'n Proto to solve this issue. It's a serialization format that's designed for shared memory and so provides data types that can be used directly with no conversion. There's a full Rust implementation for it.
-
Building High-Performance Web Services with Golang gRPC
Google thinks gRPC is fast enough for there use case. What do you consider high-performance? Plain UDP with custom TCP-like stack? https://capnproto.org/?
-
Protobuffers Are Wrong
Is Cap'n'Proto [0] as awesome as it sounds? Anyone have any first-hand experience and can speak on it?
Thanks!
is it possible to use this with gRPC?
edit: seems, not possible as of now - https://github.com/capnproto/capnproto/issues/478
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
> "Most of the logic inside the form has to be written two times: in PHP and in vue"
That's just your choice of how to build your app, right?
For an internal-facing employee tool - you could've just gone with rendering templates on the server and sending static HTML to the client. Have the business logic and validations take place on the server-side too. I'm sure you have your reasons for doing things the way you did, but it's not like there's only one way to build something like this.
> "Most enum types are repeated"
Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/
> 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.
-
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
What are some alternatives?
gRPC - The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)
Protobuf - Protocol Buffers - Google's data interchange format
FlatBuffers - FlatBuffers: Memory Efficient Serialization Library
ZeroMQ - ZeroMQ core engine in C++, implements ZMTP/3.1
MessagePack - MessagePack serializer implementation for Java / msgpack.org[Java]
Apache Avro - Apache Avro is a data serialization system.
Apache Parquet - Apache Parquet
nanomsg - nanomsg library