A reduced, refined gRPC implementation in Go



Build Report Card GoDoc

reRPC is a small framework for building HTTP APIs. You write a short API definition file and implement your application logic, and reRPC generates code to handle marshaling, routing, error handling, and content-type negotiation. It also generates an idiomatic, type-safe client.

reRPC is wire-compatible with both the gRPC and Twirp protocols, including full support for gRPC streaming. reRPC servers interoperate seamlessly with generated clients in more than a dozen languages, command-line tools like grpcurl, and proxies like Envoy and gRPC-Gateway. Thanks to Twirp's simple, human-readable JSON protocol, reRPC servers are also easy to debug with cURL.

Under the hood, reRPC is just protocol buffers and the standard library: no custom HTTP implementation, no new name resolution or load balancing APIs, and no surprises. Everything you already know about net/http still applies, and any package that works with an http.Server, http.Client, or http.Handler also works with reRPC.

For more on reRPC, including a walkthrough and a comparison to alternatives, see the docs.

A Small Example

Curious what all this looks like in practice? Here's a small h2c server:

package main

import (


  pingpb "github.com/rerpc/rerpc/internal/ping/v1test" // generated

type PingServer struct {
  pingpb.UnimplementedPingServiceReRPC // returns errors from all methods

func main() {
  ping := &PingServer{}
  mux := rerpc.NewServeMux(
  handler := h2c.NewHandler(mux, &http2.Server{})
  http.ListenAndServe(":8081", handler)

With that server running, you can make requests with any gRPC client or with cURL:

$ curl --request POST \
  --header "Content-Type: application/json" \

{"code":"unimplemented","msg":"internal.ping.v1test.PingService.Ping isn't implemented"}

You can find production-ready examples of servers and clients in the API documentation.


This is the earliest of early alphas: APIs will break before the first stable release.

Support and Versioning

reRPC supports:

Within those parameters, reRPC follows semantic versioning.


Offered under the MIT license. This is a personal project developed in my spare time - it's not endorsed by, supported by, or (as far as I know) used by my current or former employers.

  • Unify Request and Response into Message

    Unify Request and Response into Message

    Originally, we expected the generic Request and Response types to diverge quite a bit. In practice, they've ended up nearly identical. The methods we anticipate adding (primarily DisableCompression()) apply equally to both.

    The code for the two types is so similar that we're often making near-identical changes to their code. (For example, supporting trailers required verbatim copies across the two types.)

    This commit unifies the two types into connect.Message. We can then unify AnyRequest/AnyResponse and ReceiveRequest/ReceiveResponse. Since Request.Msg was never @bufdev's favorite and Message.Msg is even worse, I've renamed to Message.Body - but I'm totally open to suggestions for a better field name.

    After this PR, we've slimmed down connect's exported API quite a bit. On my monitor, the GoDoc table of contents now fits (barely) on one screen.

    opened by akshayjshah 17
  • Implement gRPC's standard interop tests

    Implement gRPC's standard interop tests

    The first-party gRPC implementations have a standardized battery of interoperability tests. Many of them test particular flags or option schemes that may not apply to us, but let's see if we can get some useful test coverage from them.


    opened by akshayjshah 12
  • Random Compression Method Selection

    Random Compression Method Selection

    Say you register 4 compression methods on both the handler and the client.

    It seems like the server picks the first compression method it recognizes, unless a specific method was used when sending the request.

    However, looking at the client side the order the methods are sent is random since it collects names from a map.

    As far as I can tell this makes it impossible to select an order of preference from the client side. Furthermore it appears to me that gzip cannot be removed from the pool, only replaced.

    opened by klauspost 11
  • More request information in Interceptor.WrapStreamContext()

    More request information in Interceptor.WrapStreamContext()

    Currently there is no way to enrich a stream context with information about the request. The WrapStreamContext() method only accepts a parent context and does not give us any information about the request.

    In particular, we need access to the endpoint spec and request headers.

    Our primary use case for this is authentication, where we would like to be able to apply some generic token parsing and validation logic to all requests, and enrich context with authentication info.

    opened by anzboi 10
  • Rename protoc-gen-go-connect to protoc-gen-goconnect/protoc-gen-connectgo?

    Rename protoc-gen-go-connect to protoc-gen-goconnect/protoc-gen-connectgo?

    The go-.* paradigm is really only used by protoc-gen-go-grpc, which is relatively new, and I'd argue that it's not productive. We generally want people to get into the habit of generating to a sub-directory named after their plugin, So we might want to have i.e /internal/gen/proto/goconnect or internal/gen/proto/connectgo, and then name the plugin accordingly.

    Note that we did the same go-.* style with our internal plugins for bufbuild/buf (this is on me), so we should probably change that too once we agree on the naming scheme.

    opened by bufdev 8
  • Possible to retrieve peer info?

    Possible to retrieve peer info?

    With grpc-go I can get peer info like so:

    p, ok := peer.FromContext(ctx)
    if !ok {
        return nil, errors.New("could not get peer from context")
    addr := p.Addr.String()

    Is it possible to do this with connect-go?

    I am trying to get the IP that the request is originating from.


    opened by eberkund 7
  • Can't detect MethodOptions

    Can't detect MethodOptions

    I am currently in the process of migrating an existing grpc api server to connect-go. Went smoothly so far, great work !

    I am actually stuck at one point, in the current implementation i detect the specified MethodOptions per service and construct ACL Rules from them.

    Example Proto

    service HealthService {
      rpc Get(HealthServiceGetRequest) returns (HealthServiceGetResponse) {
        option (visibility) = VISIBILITY_PUBLIC;

    Then i use @jhump "github.com/jhump/protoreflect/grpcreflect" to load the ServiceDescriptors and iterate through. This requires a grpc.Server instance which is not available anymore.

    Any hints howto get access to the MethodOptions with a connect-go implementation are welcome.

    opened by majst01 6
  • Support dynamic input type and output type

    Support dynamic input type and output type

    Is your feature request related to a problem? Please describe.

    Trying to build a connect gateway, support post and grpc.

    The proto is dynamic, generated from grpc reflect, but connect handler can not use the dynamic type due to handler code like this

    request = &Request[Req]{
      Msg:    new(Req),
      spec:   receiver.Spec(),
      header: receiver.Header(),

    I think connect-go can support dynamic pb type, the input and output type is based on reflect MessageType, maybe pass from HandlerOption, so NewUnaryHandler[any,any]() can work as expected.

    Describe the solution you'd like

    Describe alternatives you've considered

    Additional context

    connect protocol makes grpc eaiser, but for migration, need a gateway to translate the protocol for other languages that don't speak connect protocol.

    opened by wenerme 6
  • How to implement a

    How to implement a "full-stream" interceptor?

    Is your feature request related to a problem? Please describe. I'm struggling to understand how to implement a logging/tracing interceptor for the full Client/Server side streams. Something similar to how it was done with grpc-go, example for Elasticsearch's APM tracing: https://github.com/elastic/apm-agent-go/blob/main/module/apmgrpc/server.go#L111

    If I embed the tracing-information using WrapStreamContext (which is also missing something like Spec, to be able to identify which stream is called), how would I go about closing the transaction on end?

    Describe the solution you'd like I'd like a solution that allows for tracking the duration and result of streams, similar to how it's possible for unary calls.

    opened by bendiktv2 6
  • Fixed README examples; Set autogeneration of them using mdox tool.

    Fixed README examples; Set autogeneration of them using mdox tool.


    Huge fan here, this project is amazing! 💪🏽 It has lots of features (3 protocols in one), so I think examples has to be clear. I found the existing ones obsolete so I recreated them and committed with tooling that autogenerates them in README once changed.

    make test also checks if the examples are buildable, which will keep them up-to-date!

    Hopefully that will help make this project more accessible, cheers. Keep the good work!

    I hope you don't mind putting auto-formatter for README. It ensures consistency and e.g puts all on single line (all IDEs handle that just fine, so no point in trying to manually adjust width of text)

    Signed-off-by: Bartlomiej Plotka [email protected]

    opened by bwplotka 6
  • Evaluate Style Guide

    Evaluate Style Guide

    Package Structure

    • [x] The codec and compress packages are split out so that we can more easily add a separate package for the Protocol abstraction (e.g. gRPC, gRPC-Web, Connect) without introducing an import cycle.
    • [x] The clientstream and handlerstream packages are split out so that we can tidy up names for these types. Otherwise, you'd have names like NewClientClientStream (the client's view of a client streaming endpoint).
    • [x] We might want it to be compress.Gzip instead of compress.GzipCompressor.
      • Edit: We'll move this to compress/gzip.Compressor.

    Method Naming

    • [x] The stream has a ReceivedHeader method to distinguish itself from the request headers. Should we instead just name this ResponseHeader for clarity?
    • [x] Similarly, let's make it explicit to be RequestHeader and ResponseHeader.
    • [x] As discussed, we need to decide what we're doing with Simple/Full.
      • Client-side: WrappedPingClient and UnwrappedPingClient interfaces. PingClient is reserved for the type that users interact with.
      • Server-side: PingService (acts upon generic types), and NewPingService (acts upon any). Comments are left in-line to describe how to implement the simple, non-generic method signatures.

    Future Proofing

    • [x] Top-level abstractions (e.g. Codec and Compressor) are propagated through the clientCfg and into the protocol abstraction via a catch-all protocolClientParams. If we eventually plan to export the protocol abstraction and include it as a ClientOption, the relationship here is fuzzy.
      • What happens if we ever have a protocol that doesn't interact with all of the protocolClientParams types - is it a no-op, an error, or a silent failure?
      • We could tie these options to each protocol individually to clear these relationships up, but we end up with some more repetition (i.e. we need to repeat the same options for similar protocols like gRPC and gRPC-Web). For example, each of the gRPC and gRPC-Web protocols would have a Codec option.
      • In the connect-api branch, we were able to get around this because the protocols were separate client implementations, and they could each individually own what options they exposed (e.g. here).
    • [x] We still need to figure out error details. I know the gRPC protocol requires the proto.Any, and Akshay had some ideas around this - we could rename the methods to include Any so it leaves room for us to add other types later (e.g. AddAnyDetail). The abstraction violation between the pluggable Codec and the proto.Any sucks, but I know we're at mercy to the gRPC protocol here.

    1.0 Features

    • [x] The gRPC health and reflection packages are valuable, but they aren't really necessary to begin with. We should consider whether or not these packages should exist in a separate repository (similar to gRPC middleware repositories).
      • I know we need to be mindful of this w.r.t. including the RegistrationName in the generated code. If we were to drop this support to begin with, we'd need to reintroduce this as a HandlerOption later, and that's tied to the connect library itself. It's not immediately obvious how this would work.
      • Decision: health and reflection are staying where they are. We need these features for easy gRPC user adoption. To be clear, health is non-optional. reflection is a huge quality of life improvement and its (nearly) part of the gRPC specification at this point.
    • [x] connect.MaxHeaderBytes is kinda nice, but doesn't feel necessary and is prone to change across different protocols.
    • [x] Should connect.ReceiveResponse be in an internal package? It's only used twice and otherwise distracts from the API that users ought to interact with. This might already be your plan based on the conversations we had earlier about the user-facing API and connect internals.
      • It looks like ReceiveRequest needs to be exported for the generated code, so I can see an argument to export it for symmetry.
    • [x] Drop IsValidHeaderKey and IsValidHeaderValue.

    Implementation Details

    • [x] In the connect-api branch, I left a note for myself about whether or not the discard helper function can hang forever (e.g. discard(cs.response.Body)). This might have happened when I introduced the gRPC testing suite, but I can't recall. We need to make sure this can't happen.
      • Nothing to do here - this is a consequence of needing to read the http.Response.Body to completion to reuse the connection. This is also just an implementation detail, so it's not blocking regardless.
    opened by amckinney 6
  • Add support for Connect-Protocol-Version header

    Add support for Connect-Protocol-Version header

    Currently, it's difficult for proxies, net/http middleware, and other "in-between" code to distinguish unary Connect RPC requests from other HTTP traffic (especially with JSON payloads, which use the common application/json Content-Type). To work around this, any in-between code today must check whether the HTTP path matches a known RPC method, which requires intimate knowledge of the service schema. This isn't great.

    To work around this limitation, we've added an optional header to the specification for Connect RPC requests: Connect-Protocol-Version. Generated clients always send this header, so the vast majority of traffic should include it. Servers may require that requests include this header, which helps proxies and net/http middleware identify every Connect request. This lets in-between code function more reliably: for example, it could help a metrics-collecting reverse proxy produce higher-fidelity statistics, since it wouldn't miss even the handful of RPCs made with ad-hoc cURL commands. However, it makes ad-hoc debugging with cURL or fetch slightly more laborious.

    This PR makes clients using the Connect protocol send the Connect-Protocol-Version header, and it allows servers to opt into strict validation by using the WithRequireConnectProtocolHeader option. It makes no changes to the behavior of the gRPC or gRPC-Web protocols.

    Note that servers exposing Connect RPCs to web browsers may need to update their CORS configuration to allow the Connect-Protocol-Version header.

    opened by akshayjshah 0
  • Improve panic message on invalid handler returns

    Improve panic message on invalid handler returns

    If a handler returns nil, nil, we're going to panic during serialization. However, those stacktraces don't include any frames from the handler itself, so it's very difficult to determine what the problem is. This PR panics explicitly a bit earlier, so that we can include the procedure name in the error message.

    Fixes #405.

    opened by akshayjshah 0
  • Handler returning nil response results in cryptic stack trace.

    Handler returning nil response results in cryptic stack trace.

    Is your feature request related to a problem? Please describe. When a handler returns a nil response, it leads to a rather cryptic panic.

    func (*PingServer) Ping(
    ) (*connect.Response[pingv1.PingResponse], error) {
    	return nil, nil
    2022/11/28 09:51:26 http: panic serving runtime error: invalid memory address or nil pointer dereference
    goroutine 30 [running]:
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:1850 +0xb0
    panic({0x104c23860, 0x104f1a660})
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/runtime/panic.go:890 +0x258
            /Users/john/go/pkg/mod/github.com/bufbuild/[email protected]/connect.go:210 +0x18
    github.com/bufbuild/connect-go.NewUnaryHandler[...].func2({0x12c76ca98, 0x1400014a3e0})
            /Users/john/go/pkg/mod/github.com/bufbuild/[email protected]/handler.go:72 +0x1b8
    github.com/bufbuild/connect-go.(*Handler).ServeHTTP(0x14000108280, {0x104c969a8, 0x140001c68a0}, 0x140001ba300)
            /Users/john/go/pkg/mod/github.com/bufbuild/[email protected]/handler.go:213 +0x410
    net/http.(*ServeMux).ServeHTTP(0x0?, {0x104c969a8, 0x140001c68a0}, 0x140001ba300)
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:2487 +0x140
    net/http.(*ServeMux).ServeHTTP(0x1400006d828?, {0x104c969a8, 0x140001c68a0}, 0x140001ba300)
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:2487 +0x140
    main.logger.func1({0x104c96bb8?, 0x140001be2a0}, 0x140001ba300)
            /Users/john/Code/basic-grpc-server/main.go:84 +0xa0
    net/http.HandlerFunc.ServeHTTP(0xd0b880cd9aa8c9fb?, {0x104c96bb8?, 0x140001be2a0?}, 0x1047c596c?)
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:2109 +0x38
    golang.org/x/net/http2/h2c.h2cHandler.ServeHTTP({{0x104c94900?, 0x1400012a3f0?}, 0x14000158580?}, {0x104c96bb8, 0x140001be2a0}, 0x140001ba300)
            /Users/john/go/pkg/mod/golang.org/x/[email protected]/http2/h2c/h2c.go:124 +0x408
    net/http.serverHandler.ServeHTTP({0x104c95ab0?}, {0x104c96bb8, 0x140001be2a0}, 0x140001ba300)
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:2947 +0x2c4
    net/http.(*conn).serve(0x14000139400, {0x104c97140, 0x1400011fb00})
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:1991 +0x560
    created by net/http.(*Server).Serve
            /opt/homebrew/Cellar/go/1.19.3/libexec/src/net/http/server.go:3102 +0x444

    Describe the solution you'd like It would be nice if there was some kind of detection for this scenario, so that it's easier to tell why it crashed. The stack trace doesn't really give any clues as to which handler crashed or why, so it could be quite insidious inside a larger project.

    opened by jchadwick-buf 3
  • Distinguish between

    Distinguish between "the server ended the stream" and "the connection dropped unexpectedly"

    Is your feature request related to a problem? Please describe.

    We're using the connect protocol to stream messages from a server to a client. I seem to have misconfigured the reverse proxy in between them, so the connection drops after 30 seconds.

    What surprised me, though, was that in this case (*ServerStreamForClient).Err() returns nil, even though the client never received the end-of-stream message.

    It seems like when the connection dropped unexpectedly, the client receives an io.EOF, which is suppressed.

    If the server closed the stream and the client received the end-of-stream message, then the error is errSpecialEnvelope, which is also suppressed since it wraps io.EOF.

    It seems like it's not possible to distinguish between "the server ended the stream" and "the connection dropped unexpectedly".

    Describe the solution you'd like

    I would like (*ServerStreamForClient).Err() to only return nil if the client received the end-of-stream message from the server. If the client received io.EOF before receiving the end-of-stream message, then I would like it to return the error.

    opened by haines 1
  • document in the FAQ how client and server might access authenticated identity of the remote

    document in the FAQ how client and server might access authenticated identity of the remote

    The Peer object only provides an address. For clients, it just echos back the host that was used in the HTTP request, without returning anything about the remote server's identity. It could at least return the resolved IP, to provide more information when multiple A records are available.

    But it also provides no way to get the authenticated identity, when using TLS. This is easily available in the response object returned from the http.Client or the request object provided to the http.Handler.

    The gRPC version of this type has a generic AuthInfo field with an interface type, and users can then try to type assert to a specific implementation. The idea is that different authn mechanisms might be used to authenticate parties (like JWTs or other custom auth cookies for client authn), so the representation needs to be flexible enough so an interceptor could provide the identity (instead of hard-coding the representation used in mutually-authenticated TLS). Speaking of which, there is not a way for an authenticating interceptor to override the peer since there is no exported setter (or constructor which allows setting it).

    opened by jhump 8
  • HTTP3 support

    HTTP3 support

    Is your feature request related to a problem? Please describe.


    Describe the solution you'd like

    It would be great if Connect supported HTTP 3 workloads

    Describe alternatives you've considered

    I've tried several different solutions, like gRPC, Cap'n Proto, and libp2p-go, but any HTTP3 support is either unavailable or requires a lot of manual effort

    Additional context

    QUIC has really changed the way that modern networking can be leveraged, so it would be great to be able to leverage it through HTTP3 when building modern applications

    opened by mxplusb 4
  • v1.3.2(Dec 5, 2022)

    What's Changed


    • Send gRPC error metadata only as HTTP trailers by @akshayjshah in https://github.com/bufbuild/connect-go/pull/410

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v1.3.1...v1.3.2

    Source code(tar.gz)
    Source code(zip)
  • v1.3.1(Dec 1, 2022)

    What's Changed


    • Don't re-wrap Any when creating ErrorDetails by @jhump in https://github.com/bufbuild/connect-go/pull/409

    New Contributors

    • @jhump made their first contribution in https://github.com/bufbuild/connect-go/pull/409

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v1.3.0...v1.3.1

    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Nov 30, 2022)

    What's Changed


    • Ensure streaming http.ResponseWriters implement http.Flusher by @akshayjshah in https://github.com/bufbuild/connect-go/pull/406
    • Close TLS connection when HTTP/1.1 clients call bidi methods by @akshayjshah in https://github.com/bufbuild/connect-go/pull/408

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v1.2.0...v1.3.0

    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Nov 26, 2022)

    What's Changed


    • Allow streaming clients to only send headers by @Linniem in https://github.com/bufbuild/connect-go/pull/386
    • Add RPC protocol to Peer by @akshayjshah in https://github.com/bufbuild/connect-go/pull/394


    • Fix potential panic receiving invalid error codes by @joshcarp in https://github.com/bufbuild/connect-go/pull/398

    New Contributors

    • @Linniem made their first contribution in https://github.com/bufbuild/connect-go/pull/386

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v1.1.0...v1.2.0

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Oct 18, 2022)

    What's Changed


    • Add IsWireError to differentiate server-sent and client-synthesized errors by @joshcarp in https://github.com/bufbuild/connect-go/pull/374

    New Contributors

    • @joshcarp made their first contribution in https://github.com/bufbuild/connect-go/pull/374

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v1.0.0...v1.1.0

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Oct 4, 2022)

    What's Changed

    This is connect-go's first stable release! :tada: It doesn't contain any user-facing changes.

    We follow semantic versioning carefully, and won't make breaking changes in the 1.x series of releases.

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.5.0...v1.0.0

    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Sep 23, 2022)

    What's Changed


    • Add a helper to write RPC errors from net/http middleware by @rhbuf in https://github.com/bufbuild/connect-go/pull/337
    • Expose peer information to handlers and clients by @akshayjshah in https://github.com/bufbuild/connect-go/pull/364
    • Interoperate cleanly with http.MaxBytesHandler by @akshayjshah in https://github.com/bufbuild/connect-go/pull/355
    • Support application/json; charset=utf8 Content-Type by @buildbreaker in https://github.com/bufbuild/connect-go/pull/358


    • Fix error code for ReadMaxBytes by @akshayjshah in https://github.com/bufbuild/connect-go/pull/354

    Other changes

    • Improve test coverage of bidi streams @pkwarren in https://github.com/bufbuild/connect-go/pull/352
    • Shorten stability section of README by @akshayjshah in https://github.com/bufbuild/connect-go/pull/353
    • Add Github Actions workflow to notify on unreviewed changes by @rubensf in https://github.com/bufbuild/connect-go/pull/365

    New Contributors

    • @rhbuf made their first contribution in https://github.com/bufbuild/connect-go/pull/337

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.4.0...v0.5.0

    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Aug 17, 2022)

    What's Changed


    • Add SendMaxBytes option for clients and handlers by @pkwarren in https://github.com/bufbuild/connect-go/pull/341
    • Add client option to disable gzip support by @alexandrem in https://github.com/bufbuild/connect-go/pull/349
    • Use Go 1.19 links in GoDoc by @akshayjshah in https://github.com/bufbuild/connect-go/pull/347


    • Handle Go keywords in Protobuf definitions by @akshayjshah in https://github.com/bufbuild/connect-go/pull/348

    New Contributors

    • @rubensf made their first contribution in https://github.com/bufbuild/connect-go/pull/338
    • @alexandrem made their first contribution in https://github.com/bufbuild/connect-go/pull/349

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.3.0...v0.4.0

    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Aug 1, 2022)

    What's Changed

    Breaking Changes

    • Send binary data with error details by @akshayjshah in https://github.com/bufbuild/connect-go/pull/329
      So that proxies can translate between the Connect and gRPC protocols without a schema, we've changed the Connect protocol to include base64-encoded binary data with error details. Any code sending error details must now create details with connect.NewErrorDetail instead of anypb.New. For code unmarshaling error details, the connect.ErrorDetail type has changed from an interface to a struct with a more-ergonomic Value() method.

    Note that we will not make breaking changes in minor releases after connect-go reaches v1.0. We anticipate a stable release around October of 2022, shortly after Go 1.19 is released.

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.2.0...v0.3.0

    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Jul 18, 2022)

    What's Changed

    Breaking Changes

    • Rework streaming interceptors by @akshayjshah in https://github.com/bufbuild/connect-go/pull/316.
      To better accommodate a variety of common use cases, this release changes the interface for streaming interceptors. The new interface makes simple interceptors (like header-based authentication) easier to write, and it allows streaming handlers to recover from panics with well-formed gRPC or Connect errors. Only users with custom streaming interceptors are affected - unary interceptors are unchanged.

    Note that we will not make breaking changes in minor releases after connect-go reaches v1.0. We anticipate a stable release around October of 2022, shortly after Go 1.19 is released.


    • Add ReadMaxBytes option by @pkwarren in https://github.com/bufbuild/connect-go/pull/311
    • Add a panic-recovering interceptor by @akshayjshah in https://github.com/bufbuild/connect-go/pull/320


    • Fix path separators when generating code on Windows by @bufdev in https://github.com/bufbuild/connect-go/pull/298
    • Require grpc-status trailer with gRPC protocol by @lixin9311 and @pkwarren in https://github.com/bufbuild/connect-go/pull/288
    • Dedupe compression algorithm names by @mattrobenolt in https://github.com/bufbuild/connect-go/pull/308
    • Improve support for 32-bit platforms by @pkwarren in https://github.com/bufbuild/connect-go/pull/318
    • Map HTTP/2 RST_STREAM codes back to RPC codes by @akshayjshah in https://github.com/bufbuild/connect-go/pull/321

    New Contributors

    • @mattrobenolt made their first contribution in https://github.com/bufbuild/connect-go/pull/308

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.1.1...v0.2.0

    Source code(tar.gz)
    Source code(zip)
  • v0.1.1(Jun 6, 2022)

    What's Changed


    • Improved interceptor documentation by @abhinav in https://github.com/bufbuild/connect-go/pull/246
    • Reduce binary size by @akshayjshah in https://github.com/bufbuild/connect-go/pull/253
    • Fix compression negotiation for streaming with Connect protocol by @akshayjshah in https://github.com/bufbuild/connect-go/pull/268
    • Use registration order to prioritize client Accept-Encoding by @akshayjshah in https://github.com/bufbuild/connect-go/pull/269


    • Miscellaneous documentation fixes by @mfridman and @bufdev.
    • Guard against client stream panics by @pkwarren in https://github.com/bufbuild/connect-go/pull/265
    • Expand test coverage of codes by @pkwarren in https://github.com/bufbuild/connect-go/pull/266
    • Make HTTP internals less error-prone by @pkwarren in https://github.com/bufbuild/connect-go/pull/267

    New Contributors

    • @abhinav made their first contribution in https://github.com/bufbuild/connect-go/pull/246
    • @pkwarren made their first contribution in https://github.com/bufbuild/connect-go/pull/265

    Full Changelog: https://github.com/bufbuild/connect-go/compare/v0.1.0...v0.1.1

    Source code(tar.gz)
    Source code(zip)
  • v0.1.0(Jun 1, 2022)

    What's Changed

    This is the first public release of connect-go, a slim framework for building browser and gRPC-compatible HTTP APIs 🤩 See the blog post and connect.build for details and documentation.

    New Contributors

    Many engineers at @bufbuild worked on connect-go, but we're especially appreciative of @severb's contributions. He's our first external contributor! In alphabetical order, this release contains contributions by:

    • @akshayjshah
    • @amckinney
    • @bufdev
    • @buildbreaker
    • @cyinma
    • @doriable
    • @lrewega
    • @mfridman
    • @severb
    • @smaye81
    • @timostamm

    Full Changelog: https://github.com/bufbuild/connect-go/commits/v0.1.0

    Source code(tar.gz)
    Source code(zip)
A gRPC and Twirp-compatible RPC framework
Server and client implementation of the grpc go libraries to perform unary, client streaming, server streaming and full duplex RPCs from gRPC go introduction

Description This is an implementation of a gRPC client and server that provides route guidance from gRPC Basics: Go tutorial. It demonstrates how to u

Joram Wambugu 0 Nov 24, 2021
Raft-grpc-demo - Some example code for how to use Hashicorp's Raft implementation with gRPC

raft-grpc-example This is some example code for how to use Hashicorp's Raft impl

dougsong 1 Jan 4, 2022
A suite of gRPC debugging tools. Like Fiddler/Charles but for gRPC.

grpc-tools A suite of tools for gRPC debugging and development. Like Fiddler/Charles but for gRPC! The main tool is grpc-dump which transparently inte

Bradley Kemp 1.1k Dec 7, 2022
grpc-http1: A gRPC via HTTP/1 Enabling Library for Go

grpc-http1: A gRPC via HTTP/1 Enabling Library for Go This library enables using all the functionality of a gRPC server even if it is exposed behind a

StackRox 88 Nov 20, 2022
Go based grpc - grpc gateway micro service example

go-grpc-gateway-server This repository provides an example for go based microservice. Go micro services developed based on gRPC protobuf's and also us

Suresh Yekasiri 0 Dec 8, 2021
Simple grpc web and grpc transcoding with Envoy

gRPC Web and gRPC Transcoding with Envoy This is a simple stand-alone set of con

null 0 Dec 25, 2021
Go-grpc - This is grpc server for golang.

go-grpc This is grpc server for golang. protocのインストール brew install protoc Golang用のプラグインのインストール go install google.golang.org/protobuf/cmd/protoc-gen-go

jotaro yuza 1 Jan 2, 2022
GRPC - Creating a gRPC service from scratch

#Go gRPC services course Creating a gRPC service from scratch Command line colle

Rafael Diaz Miles 1 Jan 2, 2022
Totem - A Go library that can turn a single gRPC stream into bidirectional unary gRPC servers

Totem is a Go library that can turn a single gRPC stream into bidirectional unar

Joe Kralicky 2 Oct 12, 2022
Grpc-gateway-map-null - gRPC Gateway test using nullable values in map

Demonstrate gRPC gateway behavior with nullable values in maps Using grpc-gatewa

null 1 Jan 6, 2022
Todo-app-grpc - Go/GRPC codebase containing RealWorld examples (CRUD, auth, advanced patterns, etc)

Go/GRPC codebase containing RealWorld examples (CRUD, auth, advanced patterns, e

Sammi Aldhi Yanto 5 Oct 12, 2022
GRPC - A client-server mockup, using gRPC to expose functionality.

gRPC This is a mockup application that I built to help me visualise and understand the basic concepts of gRPC. In this exchange, the client can use a

Fergal Bittles 0 Jan 4, 2022
Benthos-input-grpc - gRPC custom benthos input

gRPC custom benthos input Create a custom benthos input that receives messages f

Marco Amador 3 Sep 26, 2022
Go-grpc-template - A small template for quickly bootstrapping a, developer platform independent gRPC golang application

go-grpc-template A small template for quickly bootstrapping a developer platform

null 1 Jan 20, 2022
Grpc-train - Train booking demo using gRPC

gRPC Demo: Train Booking Service Description Usage Contributing Development Tool

Fadi Asfour 0 Feb 6, 2022
This repo contains a sample app exposing a gRPC health endpoint to demo Kubernetes gRPC probes.

This repo contains a sample app exposing a health endpoint by implementing grpc_health_v1. Usecase is to demo the gRPC readiness and liveness probes introduced in Kubernetes 1.23.

Nico Meisenzahl 1 Feb 9, 2022
Go-grpc-tutorial - Simple gRPC server/client using go

Simple gRPC server/client using go Run server go run usermgmt_server/usermgmt_

Renner Poveda 0 Feb 14, 2022
The Go language implementation of gRPC. HTTP/2 based RPC

gRPC-Go The Go implementation of gRPC: A high performance, open source, general RPC framework that puts mobile and HTTP/2 first. For more information

grpc 17.2k Dec 4, 2022
Backend implementation using go, proto3 and gRPC for a mock online store

Backend implementation using go, proto3 and gRPC for a mock online store Ricardo RICO URIBE Tasks I - Order service The current system exposes a produ

Ricardo Rico 0 Oct 10, 2021