[HN Gopher] Connect: A Better gRPC
___________________________________________________________________
Connect: A Better gRPC
Author : slimsag
Score : 49 points
Date : 2022-06-01 16:45 UTC (6 hours ago)
(HTM) web link (buf.build)
(TXT) w3m dump (buf.build)
| codebutler wrote:
| Curious to see their typescript implementation and how it
| compares with https://github.com/stephenh/ts-proto which works
| great for grpc-web.
| melony wrote:
| Any similar frameworks for flatbuffers?
| theogravity wrote:
| Since this serves on a REST endpoint, does that mean you wouldn't
| need an envoy proxy if you want to use gRPC from the web?
| misterpigs wrote:
| Can I say _finally_ !!
| comrad wrote:
| Yeah, and i am still sad that they've removed Java RMI.
| dontlaugh wrote:
| How does it compare to Twirp, which is already well established?
| mf192 wrote:
| I think another differentiator is support for streaming. Tbh I
| am shocked at the number of folks that use streaming, but alas.
|
| It was the #3 issue opened on twirp repository, but they never
| settled on a solution.
|
| https://github.com/twitchtv/twirp/issues/3
|
| One super underrated feature Connect offers for Go devs is
| access to the request/response headers. No more plumbing
| incoming/outgoing context :phew:
| dalyons wrote:
| twirp is great. You get all the benefits of a schema'd/proto'd
| wire format (like automatic client library generation), but
| using standard http infrastructure (web servers, loadbalancers,
| etc etc) without the custom grpc routing stuff.
| akshayshah wrote:
| Twirp _is_ great. For unary RPC, Connect is similar: using the
| Connect protocol, it works over HTTP/1.1 or HTTP/2, doesn't
| require any special networking infra, and has first-class
| support for JSON payloads. In short, `curl | jq` works again.
|
| To us, the biggest difference is that Connect _also_ supports
| the gRPC and gRPC-Web protocols. That lets your code interop
| with a much, much larger ecosystem of tools and systems, many
| of which are better-supported than their Twirp equivalents.
|
| We designed the Connect protocol and the Go APIs to make multi-
| protocol support seamless. Server-side code supports the Twirp-
| like protocol and the gRPC protocols simultaneously by default.
| Clients can switch protocol with one option, no other code
| changes required.
| derekperkins wrote:
| Buf has done an amazing job simplifying the whole proto
| generation process, and now they're at it again, making gRPC
| easier to deal with. I've been using buf for years now and am
| excited to dive into connect! The team is rock solid and I love
| their development philosophies. This is a technology to bet on.
|
| No affiliation, just a fan
| mountainriver wrote:
| Very cool, love the direction and this is definitely needed
| bnajdecki wrote:
| Is there any reason that this browser compatible protocol is just
| not a part of gRPC-Web? It would be much better to maintain
| community project than building new branded project.
|
| How strongly connect relies on gRPC? Because it sounds like it's
| easy to lock in to buf's ecosystem.
| akshayshah wrote:
| In theory, there's no reason that grpc-web couldn't support a
| new protocol. That would be complicated, though; Envoy would
| also need to support it, and the gRPC team has already designed
| a protocol that they presumably like.
|
| Connect supports gRPC fully, so you shouldn't ever be locked in
| - you can always migrate systems to `grpc-go`, one piece at a
| time. We intend all the Connect projects to be community
| projects - we're happy to accept contributions, design
| proposals, and anything else. At the same time, we're
| committing our resources to keeping these projects well-
| maintained.
| racketprogram wrote:
| nice
___________________________________________________________________
(page generated 2022-06-01 23:02 UTC)