Introduction
Connect has launched! Check out the connect-go and connect-web blog posts for more info.
Connect is a family of libraries for building browser and gRPC-compatible HTTP APIs: you write a short Protocol Buffer schema and implement your application logic, and Connect generates code to handle marshaling, routing, compression, and content type negotiation. It also generates an idiomatic, type-safe client in any supported language.
Production-grade simplicity
Each Connect implementation is focused: just the essential features, built on top of time-tested HTTP libraries and designed to get out of your way. In Go, Connect is just one package — short enough to read in an afternoon.
Connect is our vision of production-grade RPC. It's simple, reliable, and
unobtrusive, because nobody has time to debug overcomplicated networking or
sift through a hundred esoteric options. Under the hood, it's just Protocol
Buffers and net/http
, fetch
, URLSession
, or your language's gold standard
for HTTP.
Most of all, Connect is stable. We take backward compatibility very seriously, and we'll never break your build after tagging a stable release.
Seamless multi-protocol support
Connect servers and clients support three protocols: gRPC, gRPC-Web, and Connect's own protocol.
Connect fully supports the gRPC protocol, including streaming, trailers, and error details. Any gRPC client, in any language, can call a Connect server, and Connect clients can call any gRPC server. We validate our gRPC compatibility with an extended version of Google's own interoperability tests.
Connect also offers direct support for the gRPC-Web protocol used by grpc/grpc-web, without relying on a translating proxy like Envoy.
Finally, Connect supports its own protocol: a straightforward, POST-only protocol that works over HTTP/1.1 and HTTP/2. It takes the best parts of gRPC and gRPC-Web, including streaming, and packages them into a protocol that's equally at home in browsers, monoliths, and microservices. The Connect protocol is what we think the gRPC protocol should be. By default, JSON- and binary-encoded Protobuf is supported. You can call our live demo service with cURL:
curl \
--header "Content-Type: application/json" \
--data '{"sentence": "I feel happy."}' \
https://demo.connect.build/buf.connect.demo.eliza.v1.ElizaService/Say
By default, Connect servers support ingress from all three protocols. Clients default to using the Connect protocol, but can switch to gRPC or gRPC-Web with a configuration toggle — no further code changes required. The APIs for errors, headers, trailers, and streaming are all protocol-agnostic.
Go and Web
Connect's Go implementation is currently in beta. We rely on it in production,
and plan to tag a stable v1 in October (soon after the Go 1.19 release). You
can get started with connect-go
now.
Connect for Web is currently in beta as well, and we have been using it in
production for a while. We plan to release a stable v1 in the fall. However,
you can get started with connect-web
now.
What's next?
Along with connect-go
and connect-web,
we've been working on a Connect
implementation for server-side TypeScript. We're still testing out the Web
Streams API in Node.js, but we anticipate having an early release ready before
the end of the year.
More broadly, working on connect-web
highlighted just how poor the client
experience is for Protobuf-based APIs — not just on the web, but also on
Android and iOS. We'd like Protobuf to be the best choice for API development
at every layer of the stack, so we're just beginning to work on Connect for
Kotlin and Swift.
Eventually, we'd like to release Connect implementations for Rails, Django, Laravel, and similar frameworks. You shouldn't have to choose between these productive toolkits and Protocol Buffers — they should work seamlessly together.