akshayshah

10 ms·

91.
Making Buf's protoc replacement faster(buf.build)
1 points by akshayshah 4y ago|0 comments
92.
Lyra: Fast, typo-tolerant, full-text search engine written in TypeScript(lyrajs.io)
1 points by akshayshah 4y ago|0 comments
93.
by akshayshah 4y ago
> But there's no reason you'd ever do the inverse, pushing protobuf schemas around with no intent to handle the wire format. You could be writing a linter, a formatter, an implementation of the Language Server Protocol, a compi
94.
by akshayshah 4y ago
Typically, schools that loop do so in fixed-size windows (often 2 years, so K/1, 2/3, etc). Often, teachers for the looped grades plan curriculum together. This tends to minimize the effects of unfamiliar subject matter and the ki
95.
by akshayshah 4y ago
Apache 2.0: https://github.com/bufbuild/protobuf.com/blob/main/LICENSE
96.
by akshayshah 4y ago
The wire format is fairly straightforward if you've seen a few binary encodings. The language used to write the schemas isn't quite as simple and regular as you might hope, though. > Maybe you mean something besides the wire fo
97.
The Protobuf Language Specification(buf.build)
194 points by akshayshah 4y ago|94 comments
98.
by akshayshah 4y ago
Only loosely related, but Robin Sloan also wrote a truly excellent article about using neural nets to produce music: https://www.mcdbooks.com/features/sourdough In his book Sourdough, he spends quite a while describing
99.
by akshayshah 4y ago
I understand the points you're raising; I'm saying that gRPC enveloping solves them. Once messages are enveloped, you _do_ have a length field for the entire message. The article is, IMO, somewhat misleading - it discusses the iss
100.
by akshayshah 4y ago
That's true of CORBA, for sure. I'm not familiar with ONC-RPC or Java RMI. It's not true of gRPC. It's not "RPC" in any traditional sense - it's just a particular HTTP convention, and the clients reflect t
101.
by akshayshah 4y ago
Is decoding performance typically a problem for web UIs? The lackluster performance of binary protobuf decoding in browsers (and unmarshaling BigInts from JSON) seems much less problematic than (1) using a 200 for unary error responses, (2)
102.
by akshayshah 4y ago
I've spent a fair bit of time working with gRPC, and you're correct - gRPC's length-prefixing makes it easy to detect when individual messages are terminated early. You do still need some way to detect streams that terminate
103.
by akshayshah 4y ago
The author also posted an interesting Twitter thread a few months ago [0], on the day my coworkers and I posted here about our gRPC-compatible RPC framework [1]. I was a bit afraid to read this post, but I shouldn't have been - the aut
104.
by akshayshah 4y ago
To be fair, it's also true that Firefox doesn't expose trailers to the fetch API. To the Chrome and gRPC team's credit, the public Chrome issue actually contains a somewhat substantive back-and-forth; the corresponding Firefo
105.
by akshayshah 4y ago
Yes, slightly - RFC 9110 ("HTTP Semantics") calls them "header fields" and "trailer fields," and it calls "headers" and "trailers" colloquialisms. In a nod to gRPC-style usage, the section o
106.
by akshayshah 4y ago
It's a variant of the gRPC-Web format that base64-encodes the request and response bodies. It was designed for very old browsers that don't support the fetch API and can't send/receive binary data. All those browsers hav
107.
by akshayshah 4y ago
Timo is amazing, and we wouldn't have been able to build any of this without him :) We ported the code generators to TypeScript because - as you guessed - it was a bit of a pain to package them for NPM. We also felt that it would be mo
108.
by akshayshah 4y ago
This is - more or less - what the Twirp and Connect protocols are.
109.
by akshayshah 4y ago
Twirp is excellent. Their protocol is _very_ similar to the Connect protocol for unary RPCs. However, the semantics that Twirp exposes are different from gRPC. That means that it's impossible (or at least _very_ awkward) to have the sa
110.
by akshayshah 4y ago
For the most part, we agree! Protobuf isn't perfect. gRPC is _definitely_ optimized for megacorporation-sized problems. No matter who you are, though, it's not fun to hand-write boilerplate data types and fetch calls or quibble ov
111.
by akshayshah 4y ago
In many ways, you're spot on. We are trying to build a business: a schema registry for Protobuf. We think that schema-driven APIs makes a lot of sense, that Protobuf is the de facto best schema language, and that the biggest gap is goo
112.
by akshayshah 4y ago
The gRPC-Web _protocol_ supports streaming - it supports everything that standard gRPC does.* The client libraries that operate in web browsers don't support client streaming, because every major browser currently buffers request bodie
113.
by akshayshah 4y ago
Unless you're all-in on server streaming, the Connect protocol is indistinguishable from RESTful HTTP to this class of L7 proxies - it's just a POST to a Protobuf-looking path, with an `application/json` or `application/
114.
by akshayshah 4y ago
tRPC is awesome - if you're writing full-stack TypeScript and don't care about other languages, it's very convenient. Protobuf might be a more appealing choice if you want to support clients in other languages, or if you&#x27
115.
by akshayshah 4y ago
Couldn't agree more, especially about the un-idiomatic libraries in many languages and gRPC's insistence on end-to-end HTTP/2 and trailer support. All of this is, in essence, what we're trying to solve with the Connect f
116.
by akshayshah 4y ago
Probably not - we wrote it alongside connect-web, so it also launched very recently :) We do think it's the best option for protobuf code generation in TypeScript, though. It comes from quite a few years of experience with proto &
117.
by akshayshah 4y ago
The little demo application is on the connect.build homepage and on https://connect.build/demo . I completely forgot to fix the redirect from demo.connect.build to point to the actual demo page - thank you for reminding me :
118.
by akshayshah 4y ago
From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If bro
119.
by akshayshah 4y ago
It's cool to see so many authz startups over the past few years! Many established companies have had some bad reliability issues (especially Auth0), and the Zanzibar paper gives that special Google sheen to new products. Authzed seems
120.
by akshayshah 4y ago
The GitHub README and docs mention that Gazette has been running in production for 5 years, but I don’t see any mention of _where_. I assume this began as an internal project at some company - does anyone know which?

More ›